[patch] convert some call ABI macros to hooks, apply to sh, add bitfield swapper
DJ Delorie
dj@redhat.com
Tue Aug 26 20:58:00 GMT 2003
> > + sh_function_arg (ca, mode, type, named)
>
> I'd appreciate if new functions were added with ISO C prototypes.
I just stuck with whatever the file already had. Personally, I'd
prefer consistency.
> > + && ((named) || !(TARGET_HITACHI || (*ca).renesas_abi)))
>
> What's this with (*ca).something? Any reason to not use ca->something
> instead?
Leftovers from the big cut-n-paste from a macro to a function. I can
clean it up more.
> > + /* dump_ca (ca, __LINE__, "in sh_function_arg_advance");*/
>
> ?!?
Leftover debugging line :-P
> > + /* True if __attribute__((renesas)) and not -mrenesas. */
>
> Err... This doesn't sound right. This seems to be true if -mrenesas
> (in both functions).
You're right, I updated the function but not the comment.
> Also, any reason for these functions to not return a bool?
No real reason. Consistency with something else, I think.
> Could I perhaps convince you to arrange for renesas_abi to be passed
> as a call cookie to non-SHcompact non-SHmedia call patterns?
You'd have to first explain what a call cookie is ;-)
> We're going to be able to tell which ABI a function uses by just
> looking at the call insn, and there's no other way to do it,
> especially in case of indirect calls (or calls made indirect after
> the callee symbol is placed in the constant pool).
Note that this is the old "pointers don't have attributes" problem.
> Are DFmode values passed in FP regs if single-only?
For sh2e they are. The abi code is quite convoluted. I've been
thinking of writing a backwards compatibility testsuite to double
check everything.
More information about the Gcc-patches
mailing list