On Thu, 2005-04-07 at 19:45, Eric Christopher wrote: > On Thu, 2005-04-07 at 16:48 +0200, Eric Botcazou wrote: > > > That was my thoughts too. You could take a look at how I fixed it on > > > ARM. > > > > Thanks. So basically you bypass the apply_result_mode array entirely, > > which > > is still wrong as it is on SPARC? > > > > Personally, I think that builtin_apply_args should go away, but what are > your thoughts on the rest of the thread. Richard didn't respond to my > last mail in the thread here: > > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02184.html > > >From my re-reading (it's been over a year here), I think the > FUNCTION_VALUE_REGNO_P "suggestion" is wrong as it's lying to the rest > of the compiler. At any rate, what entry are you getting for sparc? How > is the comment in regclass.c for reg_raw_mode's initialization not > working? > > -eric
Eric, Sorry, I dropped the ball on this one. My defence was that I concluded that whatever was done in the generic code wouldn't solve the need to use the sfm/lfm instructions on the ARM FPA, so that I didn't push it further. I agree that using 'need not' in a specification is poor terminology. The implication here though is fairly clear: a back end must list the 'base' registers used to return function values, but it does not have to list other registers that might be used to return multi-register values. (In fact, with the wording given, it does not say that values that aren't used for return values must return zero, so it could list all registers as possible return values even if they aren't. Hence, defining FUNCTION_VALUE_REGNO_P to 1 would not be an incorrect definition. But I digress...) Anyway, this means that this macro can *only* be used to test if 'regno' *might* be used as the first of possibly several consecutive registers in a return value. Changing this specification will mean testing (and most likely changing) every single back end. Changing it might also make the compiler generate less efficient code in other places that use this macro. I think if you really want to do this properly, you need to construct a number of possible return type values and call FUNCTION_VALUE on them. That will give you a series of RTX values that you can then analyse for their register usage. Beware, that on some machines values may not be returned in registers even for types that GCC considers not to be aggregates. For example, complex double might be returned in memory in some ABIs. It's not at all clear how such values would be implemented, or even if they can. Libffi can handle it, but that's just another reason to use it in preference to these builtins. R.
