| Message ID | 201109091704.p89H4IWs021430@d06av02.portsmouth.uk.ibm.com |
|---|---|
| State | Superseded |
| Headers | show |
On Sat, Sep 10, 2011 at 5:04 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote: > Hello, > > the problem in PR 50305 turned out to be caused by the ARM back-end > LEGITIMIZE_RELOAD_ADDRESS implementation. Interesting the fault goes away with -mfpu=neon, perhaps due to the DI mode operations getting pushed out into NEON registers. You might want to be explicit about the FPU in dg-options. -- Michael
On 9 September 2011 18:04, Ulrich Weigand <uweigand@de.ibm.com> wrote: > > In theory, LEGITIMIZE_RELOAD_ADDRESS could attempt to handle them by > substituting the equivalent constant and then reloading the result. > However, this might need additional steps (pushing to the constant pool, > reloading the constant pool address, ...) which would lead to significant > duplication of code from core reload. This doesn't seem worthwhile > at this point ... Thinking about it a bit more after our conversation, we do have the movw / movt instructions for armv7-a - why push this to the constant pool if we can rematerialize it ? Finding a way to use them rather than pushing things out to the constant pool might be an interesting experiment for later .. Could you let me know what configuration this was tested with ( i.e. the arch. flags ? ) and make sure this also ran through a run with the v7-a / softfp /neon configurations ? Regarding the testcase - please add an -mfloat-abi=soft to the testcase so that it tests the specific case that failed in case the default configuration was with softfp. cheers Ramana
On 26 September 2011 15:24, Ulrich Weigand <uweigand@de.ibm.com> wrote: > Ramana Radhakrishnan wrote: >> On 9 September 2011 18:04, Ulrich Weigand <uweigand@de.ibm.com> wrote: >> > >> > In theory, LEGITIMIZE_RELOAD_ADDRESS could attempt to handle them by >> > substituting the equivalent constant and then reloading the result. >> > However, this might need additional steps (pushing to the constant pool, >> > reloading the constant pool address, ...) which would lead to significant >> > duplication of code from core reload. This doesn't seem worthwhile >> > at this point ... >> >> Thinking about it a bit more after our conversation, we do have the >> movw / movt instructions for armv7-a - why push this to the constant >> pool if we can rematerialize it ? Finding a way to use them rather >> than pushing things out to the constant pool might be an interesting >> experiment for later .. > > Reload common code will already choose whatever the best option is > for reloading a constant, according to target hooks (legitimate_constant_p > and preferred_reload_class); it doesn't always push to the constant pool. > However, even on ARM there are currently certain cases where pushing to > the pool is necessary (floating point; some constants involving symbols). > I see your point. I parsed your last mail as it gets into the constant pool by default. If it does that's a separate problem. > > Is this sufficient, or should I test any other set of options as well? Could you run one set of tests with neon ? > >> Regarding the testcase - please add an -mfloat-abi=soft to the >> testcase so that it tests the specific case that failed in case the >> default configuration was with softfp. > > Just to clarify: in the presence of the other options that are already > in dg-options, the test case now fails (with the unpatched compiler) > for *any* setting of -mfloat-abi (hard, soft, or softfp). Do you still > want me to add a specific setting to the test case? No the mfpu=vfpv3 is fine. Instead of skipping I was wondering if we could prune the outputs to get this through all the testers we have. Otherwise this is OK. cheers Ramana > > Thanks, > Ulrich > > -- > Dr. Ulrich Weigand > GNU Toolchain for Linux on System z and Cell BE > Ulrich.Weigand@de.ibm.com >
On 4 October 2011 16:13, Ulrich Weigand <uweigand@de.ibm.com> wrote: > Ramana Radhakrishnan wrote: >> On 26 September 2011 15:24, Ulrich Weigand <uweigand@de.ibm.com> wrote: >> > Is this sufficient, or should I test any other set of options as well? >> >> Could you run one set of tests with neon ? > > Sorry for the delay, but I had to switch to my IGEP board for Neon > support, and that's a bit slow ... In any case, I've now completed > testing the patch with Neon with no regressions. > >> > Just to clarify: in the presence of the other options that are already >> > in dg-options, the test case now fails (with the unpatched compiler) >> > for *any* setting of -mfloat-abi (hard, soft, or softfp). Do you still >> > want me to add a specific setting to the test case? >> >> No the mfpu=vfpv3 is fine. > > OK, thanks. > >> Instead of skipping I was wondering if we >> could prune the outputs to get this through all the testers we have. > > Well, the problem is that with certain -march options (e.g. armv7) we get: > /home/uweigand/gcc-head/gcc/testsuite/gcc.target/arm/pr50305.c:1:0: > error: target CPU does not support ARM mode Ah - ok. > > Since this is an *error*, pruning the output doesn't really help, the > test isn't being run in any case. > >> Otherwise this is OK. > > Given the above, is the patch now OK as-is? OK by me. Ramana
Index: gcc/testsuite/gcc.target/arm/pr50305.c =================================================================== --- gcc/testsuite/gcc.target/arm/pr50305.c (revision 0) +++ gcc/testsuite/gcc.target/arm/pr50305.c (revision 0) @@ -0,0 +1,59 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fno-omit-frame-pointer -marm -march=armv7-a" } */ + +struct event { + unsigned long long id; + unsigned int flag; +}; + +void dummy(void) +{ + /* This is here to ensure that the offset of perf_event_id below + relative to the LANCHOR symbol exceeds the allowed displacement. */ + static int __warned[300]; + __warned[0] = 1; +} + +extern void *kmem_cache_alloc_trace (void *cachep); +extern void *cs_cachep; +extern int nr_cpu_ids; + +struct event * +event_alloc (int cpu) +{ + static unsigned long long __attribute__((aligned(8))) perf_event_id; + struct event *event; + unsigned long long result; + unsigned long tmp; + + if (cpu >= nr_cpu_ids) + return 0; + + event = kmem_cache_alloc_trace (cs_cachep); + + __asm__ __volatile__ ("dmb" : : : "memory"); + + __asm__ __volatile__("@ atomic64_add_return\n" +"1: ldrexd %0, %H0, [%3]\n" +" adds %0, %0, %4\n" +" adc %H0, %H0, %H4\n" +" strexd %1, %0, %H0, [%3]\n" +" teq %1, #0\n" +" bne 1b" + : "=&r" (result), "=&r" (tmp), "+Qo" (perf_event_id) + : "r" (&perf_event_id), "r" (1LL) + : "cc"); + + __asm__ __volatile__ ("dmb" : : : "memory"); + + event->id = result; + + if (cpu) + event->flag = 1; + + for (cpu = 0; cpu < nr_cpu_ids; cpu++) + kmem_cache_alloc_trace (cs_cachep); + + return event; +} + Index: gcc/config/arm/arm.c =================================================================== --- gcc/config/arm/arm.c (revision 178487) +++ gcc/config/arm/arm.c (working copy) @@ -6528,9 +6528,26 @@ int opnum, int type, int ind_levels ATTRIBUTE_UNUSED) { + /* We must recognize output that we have already generated ourselves. */ if (GET_CODE (*p) == PLUS + && GET_CODE (XEXP (*p, 0)) == PLUS + && GET_CODE (XEXP (XEXP (*p, 0), 0)) == REG + && GET_CODE (XEXP (XEXP (*p, 0), 1)) == CONST_INT + && GET_CODE (XEXP (*p, 1)) == CONST_INT) + { + push_reload (XEXP (*p, 0), NULL_RTX, &XEXP (*p, 0), NULL, + MODE_BASE_REG_CLASS (mode), GET_MODE (*p), + VOIDmode, 0, 0, opnum, (enum reload_type) type); + return true; + } + + if (GET_CODE (*p) == PLUS && GET_CODE (XEXP (*p, 0)) == REG && ARM_REGNO_OK_FOR_BASE_P (REGNO (XEXP (*p, 0))) + /* If the base register is equivalent to a constant, let the generic + code handle it. Otherwise we will run into problems if a future + reload pass decides to rematerialize the constant. */ + && !reg_equiv_constant (ORIGINAL_REGNO (XEXP (*p, 0))) && GET_CODE (XEXP (*p, 1)) == CONST_INT) { HOST_WIDE_INT val = INTVAL (XEXP (*p, 1));
Hello, the problem in PR 50305 turned out to be caused by the ARM back-end LEGITIMIZE_RELOAD_ADDRESS implementation. One of the arguments to the inline asm ("+Qo" (perf_event_id)) has the form (mem/c/i:DI (plus:SI (reg/f:SI 152) (const_int 1200 [0x4b0])) [5 perf_event_id+0 S8 A64]) before reload, where reg 152 holds the section anchor: (insn 23 21 29 3 (set (reg/f:SI 152) (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])) pr50305.c:36 176 {*arm_movsi_insn} (expr_list:REG_EQUAL (symbol_ref:SI ("*.LANCHOR0") [flags 0x182]) (nil))) The displacement is considered out of range for a DImode MEM, and therefore reload attempts to reload the address. The ARM LEGITIMIZE_RELOAD_ADDRESS routine then attempts to optimize this by converting the address to: (mem/c/i:DI (plus:SI (plus:SI (reg/f:SI 3 r3 [152]) (const_int 1024 [0x400])) (const_int 176 [0xb0])) [5 perf_event_id+0 S8 A64]) and pushing reloads: Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 3 r3 [152]) (const_int 1024 [0x400])) CORE_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 2) reload_in_reg: (plus:SI (reg/f:SI 3 r3 [152]) (const_int 1024 [0x400])) Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 3 r3 [152]) (const_int 1024 [0x400])) CORE_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 5) reload_in_reg: (plus:SI (reg/f:SI 3 r3 [152]) (const_int 1024 [0x400])) Reload 2: reload_in (SI) = (plus:SI (plus:SI (reg/f:SI 3 r3 [152]) (const_int 1024 [0x400])) (const_int 176 [0xb0])) CORE_REGS, RELOAD_FOR_INPUT (opnum = 2), inc by 8 reload_in_reg: (plus:SI (plus:SI (reg/f:SI 3 r3 [152]) (const_int 1024 [0x400])) (const_int 176 [0xb0])) Reload 3: reload_in (SI) = (plus:SI (plus:SI (reg/f:SI 3 r3 [152]) (const_int 1024 [0x400])) (const_int 176 [0xb0])) CORE_REGS, RELOAD_FOR_INPUT (opnum = 5), inc by 8 reload_in_reg: (plus:SI (plus:SI (reg/f:SI 3 r3 [152]) (const_int 1024 [0x400])) (const_int 176 [0xb0])) (Note that the duplicate reloads are because the "+" operand has been implicitly converted to an input and an output operand. Reloads 2/3 are there because reload is not sure that the result of LEGITIMIZE_RELOAD_ADDRESS is offsetable, and therefore reloads the whole thing anyway.) Now the problem is that some other arguments of the asm don't all fit into registers, and therefore we get a second pass through find_reloads. At this point, the insn stream has already been modified, so LEGITIMIZE_RELOAD_ADDRESS this time around sees the RTL it has itself generated at the first pass. However, it is not able to recognize this, and therefore doesn't re-generate the required reloads, so instead generic code attempts to handle the nested plus, and creates somewhat unfortunate reloads: Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 3 r3 [152]) (const_int 176 [0xb0])) CORE_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 2) reload_in_reg: (plus:SI (reg/f:SI 3 r3 [152]) (const_int 176 [0xb0])) Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 3 r3 [152]) (const_int 176 [0xb0])) CORE_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 5) reload_in_reg: (plus:SI (reg/f:SI 3 r3 [152]) (const_int 176 [0xb0])) Reload 2: reload_out (SI) = (reg:SI 151 [ tmp ]) GENERAL_REGS, RELOAD_FOR_INSN (opnum = 1) reload_out_reg: (reg:SI 151 [ tmp ]) Reload 3: reload_in (SI) = (plus:SI (plus:SI (reg/f:SI 3 r3 [152]) (const_int 176 [0xb0])) (const_int 1024 [0x400])) CORE_REGS, RELOAD_FOR_INPUT (opnum = 2), inc by 8 reload_in_reg: (plus:SI (plus:SI (reg/f:SI 3 r3 [152]) (const_int 176 [0xb0])) (const_int 1024 [0x400])) Reload 4: reload_in (SI) = (plus:SI (plus:SI (reg/f:SI 3 r3 [152]) (const_int 176 [0xb0])) (const_int 1024 [0x400])) CORE_REGS, RELOAD_FOR_INPUT (opnum = 5), inc by 8 reload_in_reg: (plus:SI (plus:SI (reg/f:SI 3 r3 [152]) (const_int 176 [0xb0])) (const_int 1024 [0x400])) This can be fixed by having LEGITIMIZE_RELOAD_ADDRESS recognize RTL it has generated itself in a prior pass (note that several other back-ends already have a corresponding fix). However, even then, the test case still fails. This is because we then emit reloads that compute (plus:SI (reg 152) (const_int 1024)). But, reg 152 was marked as equivalent to a constant (the LANCHOR address). Also, reload needed another register, and decided to spill reg 152 from its preliminary home in reg 3. Since the register was equivalent to a constant, it is not spilled on the stack; instead, reload assumes that all uses would get reloaded to a rematerialization of the equivalent constant. This is in fact what reload itself will do; but this doesn't happen if the reload is generated by LEGITIMIZE_RELOAD_ADDRESS. In theory, LEGITIMIZE_RELOAD_ADDRESS could attempt to handle them by substituting the equivalent constant and then reloading the result. However, this might need additional steps (pushing to the constant pool, reloading the constant pool address, ...) which would lead to significant duplication of code from core reload. This doesn't seem worthwhile at this point ... Therefore, the patch below fixes this second issue by simply not handling addresses based on a register equivalent to a constant at all in LEGITIMIZE_RELOAD_ADDRESS. In general, common code should do a good enough job for those anyway ... Tested on arm-linux-gnueabi with no regressions, fixes the testcase. OK for mainline? Bye, Ulrich ChangeLog: gcc/ PR target/50305 * config/arm/arm.c (arm_legitimize_reload_address): Recognize output of a previous pass through legitimize_reload_address. Do not attempt to optimize addresses if the base register is equivalent to a constant. gcc/testsuite/ PR target/50305 * gcc.target/arm/pr50305.c: New test.