Georg-Johann Lay <avr@xxxxxxxx> writes: > A function shall pass addresses in A-registers and other stuff in > D-registers, Pmode = SImode. How do varargs functions work? > 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. Ian
