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

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> On Mon, Mar 03, 2003 at 07:17:47PM -0500, John David Anglin wrote:
> > xmpyu was not used because the option -mdisable-fpregs was used,
> > disabling the pattern.  The test code is from a parisc-linux
> > kernel build.  Whether it is this is the best choice on a PA 2
> > machine, I'm not sure.
> 
> Would it be feasable to simply make all of the fpregs call-saved?
> Alternately, leave a few of them unfixed, as we do with ia64.

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.

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.

The final option might be to use the 32-bit $$mulI millicode routine
instead of the __muldi3 libcall.  It doesn't use the stack or create
a frame.  The downside is it only produces a 32-bit result.

Dave
-- 
J. David Anglin                                  dave dot anglin at nrc-cnrc dot gc dot ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)