This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RFC: split_complex_args enhancement
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: rth at redhat dot com, amodra at bigpond dot net dot au, gcc at gcc dot gnu dot org
- Date: Wed, 17 Nov 2004 14:16:57 -0400
- Subject: RFC: split_complex_args enhancement
Hi folks.
I'm contemplating using SPLIT_COMPLEX_ARG for e500v2. Since, we must
maintain ABI compatability with classic soft-float, SPLIT_COMPLEX_ARGS
seems like the logical choice to pass things in GPRs, and not have
GCC get confused with my (somewhat) 64-bit registers.
I tried this approach and it almost worked. The problem is that, on
32-bit PPC, any 2 word items are stored in GPRs starting on an odd
register:
void foo(int arg1, __complex__ float arg2);
foo() would expect arg1 in r3, but arg2 in [r5, r6].
If I use SPLIT_COMPLEX_ARG, I lose all knowledge of the argument being
a complex, so FUNCTION_ARG sees consecutive SFmode's, which it puts in
[r4, r5].
If we kept knowledge of the floats being part of a complex, I could
handle this correctly in FUNCTION_ARG. But I doubt anyone will like
adding a field to "struct tree_type". Perhaps using an unused field?
My previous attempt at generating parallels was somewhat of a pain,
because GCC kept falling on its face because I had a 64-bit GPR that
shouldn't store the entire SCmode. I could try this approach again,
but I'm hoping the SPLIT_COMPLEX_ARG can be taught new tricks.
Ideas?
Aldy