Re: Is the loop pass allowed to introduce new call insns?

[law at redhat dot com]

In message <200303040524 dot h245ONJe011437 at hiauly1 dot hia dot nrc dot ca>, "John David 
Anglin" writes:
 >I'd have to run the idea past the kernel people.  It would improve
 >multiplication performance at the expense of context switching for
 >the unfixed fpregs.
Yup.  I had guessed the point behind this was to avoid FP regs in
the kernel.  We did the same things when I used to kernel work on
PAs.

 >I have hacked the pa call patterns to not use the virtual outgoing
 >args register after instantiation.  This can fail if insufficient
 >argument space is allocated.  But I suspect that when loop generates
 >an add-multiply there already will be a similar set of libcalls
 >in the loop and we won't need any additional arg space.  It fixes the
 >test compile.  We allocate stack space for 8 DI mode argument registers
 >whenever there is a call.
About the only way I can see not having a call before loop and 
having one after would be if we somehow had implemented the multiply
by shifts/adds, etc, but then transformed it back into a mult insn.
I don't know if this can actually happen.

 >The final option might be to use the 32-bit $$mulI millicode routine
I suspect muldi3 will just call the 32bit multipliers anyway, so this
may not be a bad idea.

jeff