* 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 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-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-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).