This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]