Richard Earnshaw schrieb:
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...
Yes, definitely.
But optabs.c::init_one_libfunc() does not investigate in building a
proper SYMBOL_REF_DECL. It just creates a dummy tree to set some flags
like DECL_ARTIFICIAL and nullifies it afterwards. As a result,
SYMBOL_REF_DECL(LIBNAME) is NULL_TREE in FUNCTION_ARG et al.
What I do not understand is how the ABI can be different, because the
callee will expect the arguments in dedicated registers, regardless of
who calls it and of wether or not the caller issues a user call or a
support call.
As I read in
http://gcc.gnu.org/viewvc/branches/ARM/hard_vfp_4_4_branch/gcc/doc/tm.texi?r1=142586&r2=142592&diff_format=h
you solved the shortcomings of LIBCALL_VALUE, which are basically the
same as these of FUNCTION_ARG* if the target has ptr_mode=word_mode :-)
Will this get into the next official 4.3.x release? I hope so!
Georg-Johann
