* Is the loop pass allowed to introduce new call insns?
@ 2003-03-03 20:51 John David Anglin
2003-03-03 22:20 ` Richard Henderson
2003-03-04 0:20 ` law
0 siblings, 2 replies; 12+ messages in thread
From: John David Anglin @ 2003-03-03 20:51 UTC (permalink / raw)
To: gcc; +Cc: rth
I have an ICE that I am investigating for hppa64-unknown-linux-gnu
but it also occurs on hppa64-hp-hpux11.11 compiling the same code.
The loop pass pulls some stuff out of a loop and generates a new
call to __muldi3. On hppa64, this generates a new set to load the
arg pointer for the call using the virtual-outgoing-args register.
However, virtual registers already been instantiated and this leads
to an ICE when the insn doesn't match its constraints.
Is the loop pass allowed to introduce new calls? If it is, then
it would appear that it needs to redo instantiate_virtual_regs.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is the loop pass allowed to introduce new call insns?
2003-03-03 20:51 Is the loop pass allowed to introduce new call insns? John David Anglin
@ 2003-03-03 22:20 ` Richard Henderson
2003-03-03 23:12 ` John David Anglin
2003-03-04 0:20 ` law
1 sibling, 1 reply; 12+ messages in thread
From: Richard Henderson @ 2003-03-03 22:20 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc
On Mon, Mar 03, 2003 at 03:47:25PM -0500, John David Anglin wrote:
> Is the loop pass allowed to introduce new calls? If it is, then
> it would appear that it needs to redo instantiate_virtual_regs.
It's allowed to move calls. I wouldn't have expected it to
generate new ones. I guess I can see why it might have, with
refactoring IVs, but I wouldn't have expected it to *find*
an IV that needed libcalls.
We can't redo instantiate_virtual_regs at this point. Or
rather, we can't change the decisions that we made then.
Not sure what to do about this...
r~
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is the loop pass allowed to introduce new call insns?
2003-03-03 22:20 ` Richard Henderson
@ 2003-03-03 23:12 ` John David Anglin
2003-03-04 1:03 ` Richard Henderson
0 siblings, 1 reply; 12+ messages in thread
From: John David Anglin @ 2003-03-03 23:12 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc
> Not sure what to do about this...
Maybe I can stop this by adding "!virtuals_instantiated" to the
condition for the various call expanders.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is the loop pass allowed to introduce new call insns?
2003-03-03 20:51 Is the loop pass allowed to introduce new call insns? John David Anglin
2003-03-03 22:20 ` Richard Henderson
@ 2003-03-04 0:20 ` law
2003-03-04 0:55 ` John David Anglin
1 sibling, 1 reply; 12+ messages in thread
From: law @ 2003-03-04 0:20 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, rth
In message <200303032047.h23KlPk6019968@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
>I have an ICE that I am investigating for hppa64-unknown-linux-gnu
>but it also occurs on hppa64-hp-hpux11.11 compiling the same code.
>The loop pass pulls some stuff out of a loop and generates a new
>call to __muldi3. On hppa64, this generates a new set to load the
>arg pointer for the call using the virtual-outgoing-args register.
>However, virtual registers already been instantiated and this leads
>to an ICE when the insn doesn't match its constraints.
>
>Is the loop pass allowed to introduce new calls? If it is, then
>it would appear that it needs to redo instantiate_virtual_regs.
Q. Why did the expander create a call to __muldi3 -- shouldn't it
have used xmpyu? Not that it would solve the underlying problem, but
it seems odd to not use xmpyu in this case.
Jeff
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is the loop pass allowed to introduce new call insns?
2003-03-04 0:20 ` law
@ 2003-03-04 0:55 ` John David Anglin
2003-03-04 1:22 ` Richard Henderson
0 siblings, 1 reply; 12+ messages in thread
From: John David Anglin @ 2003-03-04 0:55 UTC (permalink / raw)
To: law; +Cc: gcc, rth
> Q. Why did the expander create a call to __muldi3 -- shouldn't it
> have used xmpyu? Not that it would solve the underlying problem, but
> it seems odd to not use xmpyu in this case.
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.
I think the call patterns can be modified to handle this situation
provided the call doesn't need more argument space than has been
allocated.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is the loop pass allowed to introduce new call insns?
2003-03-03 23:12 ` John David Anglin
@ 2003-03-04 1:03 ` Richard Henderson
0 siblings, 0 replies; 12+ messages in thread
From: Richard Henderson @ 2003-03-04 1:03 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc
On Mon, Mar 03, 2003 at 05:20:45PM -0500, John David Anglin wrote:
> Maybe I can stop this by adding "!virtuals_instantiated" to the
> condition for the various call expanders.
Nope. That will only cause an abort at best. One has to prevent
the call to expand_libcall_value.
r~
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is the loop pass allowed to introduce new call insns?
2003-03-04 0:55 ` John David Anglin
@ 2003-03-04 1:22 ` Richard Henderson
2003-03-04 5:29 ` John David Anglin
0 siblings, 1 reply; 12+ messages in thread
From: Richard Henderson @ 2003-03-04 1:22 UTC (permalink / raw)
To: John David Anglin; +Cc: law, gcc
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.
r~
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is the loop pass allowed to introduce new call insns?
2003-03-04 1:22 ` Richard Henderson
@ 2003-03-04 5:29 ` John David Anglin
2003-03-04 7:40 ` Richard Henderson
2003-03-06 16:15 ` law
0 siblings, 2 replies; 12+ messages in thread
From: John David Anglin @ 2003-03-04 5:29 UTC (permalink / raw)
To: Richard Henderson; +Cc: law, gcc
> 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.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is the loop pass allowed to introduce new call insns?
2003-03-04 5:29 ` John David Anglin
@ 2003-03-04 7:40 ` Richard Henderson
2003-03-04 8:35 ` John David Anglin
2003-03-06 16:15 ` law
1 sibling, 1 reply; 12+ messages in thread
From: Richard Henderson @ 2003-03-04 7:40 UTC (permalink / raw)
To: John David Anglin; +Cc: law, gcc
On Tue, Mar 04, 2003 at 12:24:23AM -0500, John David Anglin wrote:
> 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.
You'd only need one or two fpregs. That shouldn't be much
of a burden at all.
r~
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is the loop pass allowed to introduce new call insns?
2003-03-04 7:40 ` Richard Henderson
@ 2003-03-04 8:35 ` John David Anglin
0 siblings, 0 replies; 12+ messages in thread
From: John David Anglin @ 2003-03-04 8:35 UTC (permalink / raw)
To: Richard Henderson; +Cc: law, gcc
> On Tue, Mar 04, 2003 at 12:24:23AM -0500, John David Anglin wrote:
> > 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.
>
> You'd only need one or two fpregs. That shouldn't be much
> of a burden at all.
It turns out that all fpregs are currently saved. The main reason
fpregs are disabled is to ensure that no floating-point exceptions
are raised in the kernel.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is the loop pass allowed to introduce new call insns?
2003-03-04 5:29 ` John David Anglin
2003-03-04 7:40 ` Richard Henderson
@ 2003-03-06 16:15 ` law
2003-03-09 20:17 ` [PATCH]: " John David Anglin
1 sibling, 1 reply; 12+ messages in thread
From: law @ 2003-03-06 16:15 UTC (permalink / raw)
To: John David Anglin; +Cc: Richard Henderson, gcc
In message <200303040524.h245ONJe011437@hiauly1.hia.nrc.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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH]: Re: Is the loop pass allowed to introduce new call insns?
2003-03-06 16:15 ` law
@ 2003-03-09 20:17 ` John David Anglin
0 siblings, 0 replies; 12+ messages in thread
From: John David Anglin @ 2003-03-09 20:17 UTC (permalink / raw)
To: law; +Cc: rth, gcc, gcc-patches
I have installed the following on 3.3 and the trunk to fix the ICE
building the linux 64-bit kernel with "-mdisable-fpregs". In the
coming week, I hope to add support for a "-mfixed-range=" option
to allow use of a limited number of fpregs and xmpyu (actually the linux
people are already using xmpyu in __muldi3 since they didn't build libgcc.a
with "-mdisable-fpregs"), and possibly support for 64-bit integer
multiplication using $$mulI.
Tested on hppa64-hp-hpux11*, 3.3 and trunk.
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2003-08-09 John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
* pa.md (call, call_value, sibcall, sibcall_value): When sufficient
space has been allocated for the outgoing arguments, set the arg
pointer for a call emitted after virtuals have been instantiated
using the stack pointer offset, otherwise abort.
Index: config/pa/pa.md
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa.md,v
retrieving revision 1.122
diff -u -3 -p -r1.122 pa.md
--- config/pa/pa.md 5 Mar 2003 22:40:21 -0000 1.122
+++ config/pa/pa.md 5 Mar 2003 23:00:27 -0000
@@ -5889,9 +5889,26 @@
op = XEXP (operands[0], 0);
if (TARGET_64BIT)
- emit_move_insn (arg_pointer_rtx,
- gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx,
- GEN_INT (64)));
+ {
+ if (!virtuals_instantiated)
+ emit_move_insn (arg_pointer_rtx,
+ gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx,
+ GEN_INT (64)));
+ else
+ {
+ /* The loop pass can generate new libcalls after the virtual
+ registers are instantiated when fpregs are disabled because
+ the only method that we have for doing DImode multiplication
+ is with a libcall. This could be trouble if we haven't
+ allocated enough space for the outgoing arguments. */
+ if (INTVAL (nb) > current_function_outgoing_args_size)
+ abort ();
+
+ emit_move_insn (arg_pointer_rtx,
+ gen_rtx_PLUS (word_mode, stack_pointer_rtx,
+ GEN_INT (STACK_POINTER_OFFSET + 64)));
+ }
+ }
/* Use two different patterns for calls to explicitly named functions
and calls through function pointers. This is necessary as these two
@@ -6372,9 +6389,26 @@
op = XEXP (operands[1], 0);
if (TARGET_64BIT)
- emit_move_insn (arg_pointer_rtx,
- gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx,
- GEN_INT (64)));
+ {
+ if (!virtuals_instantiated)
+ emit_move_insn (arg_pointer_rtx,
+ gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx,
+ GEN_INT (64)));
+ else
+ {
+ /* The loop pass can generate new libcalls after the virtual
+ registers are instantiated when fpregs are disabled because
+ the only method that we have for doing DImode multiplication
+ is with a libcall. This could be trouble if we haven't
+ allocated enough space for the outgoing arguments. */
+ if (INTVAL (nb) > current_function_outgoing_args_size)
+ abort ();
+
+ emit_move_insn (arg_pointer_rtx,
+ gen_rtx_PLUS (word_mode, stack_pointer_rtx,
+ GEN_INT (STACK_POINTER_OFFSET + 64)));
+ }
+ }
/* Use two different patterns for calls to explicitly named functions
and calls through function pointers. This is necessary as these two
@@ -6868,15 +6902,32 @@
"!TARGET_PORTABLE_RUNTIME"
"
{
- rtx op;
- rtx call_insn;
+ rtx op, call_insn;
+ rtx nb = operands[1];
op = XEXP (operands[0], 0);
if (TARGET_64BIT)
- emit_move_insn (arg_pointer_rtx,
- gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx,
- GEN_INT (64)));
+ {
+ if (!virtuals_instantiated)
+ emit_move_insn (arg_pointer_rtx,
+ gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx,
+ GEN_INT (64)));
+ else
+ {
+ /* The loop pass can generate new libcalls after the virtual
+ registers are instantiated when fpregs are disabled because
+ the only method that we have for doing DImode multiplication
+ is with a libcall. This could be trouble if we haven't
+ allocated enough space for the outgoing arguments. */
+ if (INTVAL (nb) > current_function_outgoing_args_size)
+ abort ();
+
+ emit_move_insn (arg_pointer_rtx,
+ gen_rtx_PLUS (word_mode, stack_pointer_rtx,
+ GEN_INT (STACK_POINTER_OFFSET + 64)));
+ }
+ }
/* Indirect sibling calls are not allowed. */
if (TARGET_64BIT)
@@ -6933,15 +6984,32 @@
"!TARGET_PORTABLE_RUNTIME"
"
{
- rtx op;
- rtx call_insn;
+ rtx op, call_insn;
+ rtx nb = operands[1];
op = XEXP (operands[1], 0);
if (TARGET_64BIT)
- emit_move_insn (arg_pointer_rtx,
- gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx,
- GEN_INT (64)));
+ {
+ if (!virtuals_instantiated)
+ emit_move_insn (arg_pointer_rtx,
+ gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx,
+ GEN_INT (64)));
+ else
+ {
+ /* The loop pass can generate new libcalls after the virtual
+ registers are instantiated when fpregs are disabled because
+ the only method that we have for doing DImode multiplication
+ is with a libcall. This could be trouble if we haven't
+ allocated enough space for the outgoing arguments. */
+ if (INTVAL (nb) > current_function_outgoing_args_size)
+ abort ();
+
+ emit_move_insn (arg_pointer_rtx,
+ gen_rtx_PLUS (word_mode, stack_pointer_rtx,
+ GEN_INT (STACK_POINTER_OFFSET + 64)));
+ }
+ }
/* Indirect sibling calls are not allowed. */
if (TARGET_64BIT)
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-03-09 20:11 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-03 20:51 Is the loop pass allowed to introduce new call insns? John David Anglin
2003-03-03 22:20 ` Richard Henderson
2003-03-03 23:12 ` John David Anglin
2003-03-04 1:03 ` Richard Henderson
2003-03-04 0:20 ` law
2003-03-04 0:55 ` John David Anglin
2003-03-04 1:22 ` Richard Henderson
2003-03-04 5:29 ` John David Anglin
2003-03-04 7:40 ` Richard Henderson
2003-03-04 8:35 ` John David Anglin
2003-03-06 16:15 ` law
2003-03-09 20:17 ` [PATCH]: " John David Anglin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).