[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