On Wed, 2009-04-29 at 08:57 -0700, Ian Lance Taylor wrote: > > Everything works fine except that for libcalls the target macros > > FUNCTION_ARG, FUNCTION_ARG_ADVANCE, TARGET_PASS_BY_REFERENCE et > > al. are called with TYPE=NULL_TREE, so that is is not possible to > > destinguish between pointers and non-pointers. > > > > If the call of memmove is done explicitely from the C source, then > > there is a prototype and TYPE!=NULL_TREE so that I can provide correct > > behaviour for the target hooks mentioned above. > > > > But, if memmove is called implicitely to copy function args like large > > structs that are passed in memory, then TYPE==NULL_TREE and the hooks > > have no information about what they have to do. Neigher choosing an > > A-reg not choosing a D-reg will yield a consistend calling conventions > > in every case. > > > > Did I miss something? Is there a way to retrieve the necessary > > information without hacking calls.c, function.c, etc? > > > > Why is this essential information cancelled in calls.c? > > Obviously, calls.c has that information but hides it from the backend. > > Yours is the first processor I have heard of which uses this sort of > calling convention. Differentiating on the basis of integer > vs. floating point is common, on the basis of integer vs. pointer is > not. I can see that you have a problem, but I'm not surprised that gcc > does not already address it. You are going to have to figure out what > is required to make it work. Modifying libcalls to be more like > ordinary functions sounds like a good approach; it is one that gcc has > been following, very slowly, for many years. Hmm, the ARM port has something similar, which only comes to be significant when the hard-float calling convention is implemented; in this case, the calling convention for the ABI-specified support functions remains unchanged even though the calling convention for normal user calls can be different. The trick is that you have to find out exactly which libcall is being used, essentially by name matching. You can look at what I've done for this on the ARM/hard_vfp_4_4_branch in the GCC SVN repository. It's unfortunate that GCC doesn't synthesise a type node for libcalls; that would probably make things much simpler... R.
