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]

pushing values to memory efficiently during rtl gen?



Here is the issue I am trying to solve.

Library calls on sparc-v9 for quad precision floating point when it
must be done in software take most arguments in memory instead of in
registers.  Also return values are passed via a pointer to the result
value.  Previous versions of the ABI passed them all in registers.
For example:

/* Add TFmode values 'a' and 'b', place the result in 'c' */
void _Qp_add (long double *c, const long double *a, const long double *b);

I'm going to now have to perform some magic in the expanders so that I
can get this to operate correctly.

My question is that how can I efficiently push the REGs passed to the
RTL expanders into memory so I can set up the args to the libcall
correctly?

One neat trick which has been pointed out to me, and looks promising,
is to wrap the REGs in an ADDRESSOF.  As I look it seems that I have
to tack on the tree code for the value into there for this to work
correctly.  Or can I forego the tree code and just stick NULL there?

Else, are there other ways?  I suppose I could allocate stack
temporaries each time, but that seems like it wouldn't result in very
good code generation in the end.  For example, if I did it this way
would the compiler later be able to optimize it all away, as in:

      void foo(long double *a, long double *b, long double *c)
      {
	*a = *b + *c;
      }

Ideally I'd like this to result in directly passing foo's pointer
parameters into the _Qp_add() libcall.  I am fairly certain the
ADDRESSOF mechanism would get this optimization, but for the normal
stack temporary scheme I am not so sure.

Comments?

Later,
David S. Miller
davem@dm.cobaltmicro.com


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