[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.3 |4.6.4 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-01 14:38:50 UTC --- GCC 4.6.3 is being released.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #21 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-22 09:25:48 UTC --- Author: gjl Date: Wed Feb 22 09:25:35 2012 New Revision: 184461 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184461 Log: PR rtl-optimization/50063 * config/avr/avr.md (movhi_sp_r): Handle -1 (unknown IRQ state) and 2 (8-bit SP) in operand 2. * config/avr/avr.c (avr_prologue_setup_frame): Adjust prologue setup to use movhi_sp_r instead of vanilla move to write SP. Adjust REG_CFA notes to superseed unspec. (expand_epilogue): Adjust epilogue setup to use movhi_sp_r instead of vanilla move. As function body might contain CLI or SEI: Use irq_state 0 (IRQ known to be off) only with TARGET_NO_INTERRUPTS. Never use irq_state 1 (IRQ known to be on) here. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #19 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-20 13:41:39 UTC --- FYI, after updating to SVN 184386 (2012-02-20) I see 14 new FAILs in the avr test suite; all of which can be cured with -fno-dse: FAIL: gcc.c-torture/execute/20020215-1.c execution, -O1 FAIL: gcc.c-torture/execute/20020215-1.c execution, -Os FAIL: gcc.c-torture/execute/930126-1.c execution, -O1 FAIL: gcc.c-torture/execute/991118-1.c execution, -O1 FAIL: gcc.c-torture/execute/991118-1.c execution, -Os FAIL: gcc.c-torture/execute/bf64-1.c execution, -O1 FAIL: gcc.c-torture/execute/bf64-1.c execution, -Os FAIL: gcc.c-torture/execute/pr51877.c execution, -O1 FAIL: gcc.c-torture/execute/pr51877.c execution, -O2 FAIL: gcc.c-torture/execute/pr51877.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/pr51877.c execution, -O3 -g FAIL: gcc.c-torture/execute/pr51877.c execution, -Os plugin -flto-partition=none FAIL: gcc.c-torture/execute/pr51877.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/pr51877.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 13:52:50 UTC --- Please just fix up your backend, e.g. by turning that sp = hfp move (insn 47 above) into an UNSPEC move.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||denisc at gcc dot gnu.org --- Comment #18 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-12-22 00:03:08 UTC --- From what you wrote the internals documentation need to be fixed, i.e. there should be a disclaimer in expand_prologue documentation that SP=FP is an illegal configuration that breaks GCC. Moreover there is: FIND_BASE_TERM (x): It is always safe for this macro to not be defined. Which is obviously wrong. I don't know enough of alias internals, but I get more and more the impression that implementing FIND_BASE_TERM is just working around problem in generic code and instead of backend hacking around it the generic code should be made robust. At the moment I tend to deactivate malicous pass(es) in the backend until they use robust approach and don't value performance higher than correctness.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 18:34:16 UTC --- I believe this is just because of very weird target avr stuff, either it is a target bug that can be fixed up in the backend somehow, or perhaps would need some middle-end help, but still it is avr specific. Doesn't seem to have anything to do with PR49330. The problem seems to be that the prologue here looks like: (insn/f 43 7 44 2 (set (mem/c:QI (post_dec:HI (reg/f:HI 32 __SP_L__)) [5 S1 A8]) (reg:QI 28 r28)) pr50063.c:9 -1 (nil)) (insn/f 44 43 45 2 (set (mem/c:QI (post_dec:HI (reg/f:HI 32 __SP_L__)) [5 S1 A8]) (reg:QI 29 r29)) pr50063.c:9 -1 (expr_list:REG_DEAD (reg:QI 29 r29) (nil))) (insn 45 44 46 2 (set (reg/f:HI 28 r28) (reg/f:HI 32 __SP_L__)) pr50063.c:9 -1 (nil)) (insn/f 46 45 47 2 (set (reg/f:HI 28 r28) (plus:HI (reg/f:HI 28 r28) (const_int -12 [0xfff4]))) pr50063.c:9 -1 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:HI 28 r28) (plus:HI (reg/f:HI 32 __SP_L__) (const_int -12 [0xfff4]))) (nil))) (insn 47 46 48 2 (set (reg/f:HI 32 __SP_L__) (reg/f:HI 28 r28)) pr50063.c:9 -1 (nil)) where reg 28 is frame pointer and reg 32 is stack pointer. When canon_true_dependence is called by DSE, one of the mem addresses is r28 plus CONST_INT, the other is a VALUE, which is in the end a VALUE of r28 plus some offset. But r28 (frame pointer) and r32 (stack pointer) have the same VALUE in this case, and because of the initialization of sp from fp r32 is actually before r28 in that VALUE's locs list. So, find_base_term for that VALUE returns (address r32), while find_base_term for r28 plus CONST_INT doesn't use cselib values at all and thus returns (address r28) and base_alias_check just fails. The question is why avr does this, and if it really has to do that, it should make sure somehow that for the alias analysis either REG_BASE_VALUE of r28 is the same as REG_BASE_VALUE of r32. E.g. it could define FIND_BASE_TERM and do something for r28/r32 if they are known to be the same. init_alias_analysis ignores prologue and epilogue insns after reload, which is probably why record_set isn't called here on the r32 = r28 set.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #13 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-12-19 18:56:49 UTC --- (In reply to comment #12) I believe this is just because of very weird target avr stuff, either it is a target bug that can be fixed up in the backend somehow, or perhaps would need some middle-end help, but still it is avr specific. The insns describe exactly what the machine is doing: insn 43/44: Save FP (r28/29) to Stack. This in done in two QI pushes and not in one HI. SP push is post-decrement and with a HI push the resulting address would be wrong. AVR is 8-bit machine with 16-bit PMODE. insn 45: Initialize FP with SP insn 46: Set up a frame (12 bytes here). AVR's SP cannot be changed directly, not even atomically so changing SP is quite expensive and IRQs must be turned off. Therefore, prologue generation works out two methods of setting up frame/changing SP and picks the most efficient: * For big offsets it is: FP = SP; FP -= const; SP = FP * For small offsets SP is adjusted by dummy pushes/pops, for example: SP -= 2 as of: push(dummy); push(dummy); FP = SP Similar applies to epilogue generation. This example exercises the first approach. The 3rd step is (SP = FP): insn 47: Write back SP If the generic analysis ignores prologue/epilogue but optimizers optimize against prologue/epilogue using that incorrect information based on lazy analysis, then the problem is in generic code.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P4 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-19 19:12:56 UTC --- Well, it is certainly desirable not to process the prologue insns during init_alias_analysis. The fact that stack pointer has the same value as frame pointer after the prologue is not usual and something the generic code isn't prepared for (usually either frame pointer is eliminated (of course then the register can be used for something else) or frame pointer is initialized from stack pointer and then decremented (or incremented) still inside of the prologue). So you need to tell the alias analysis about that, as the prologue isn't scanned, it is the backend responsibility to tell that.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #15 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-12-19 23:24:13 UTC --- (In reply to comment #14) Well, it is certainly desirable not to process the prologue insns during init_alias_analysis. The fact that stack pointer has the same value as frame pointer after the prologue is not usual and something the generic code isn't prepared for. So bottom line is that GCC is not ready for AVR? So you need to tell the alias analysis about that, as the prologue isn't scanned, it is the backend responsibility to tell that. Ya, I skimmed the hooks once again... What hook needs to be implemented/adjusted by AVR backend to ship that information if prologue and elimination information is not enough already...?
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-20 00:22:19 UTC --- Well, you or whomever wants to fix this bug needs to propose some solution. I'm not familiar with avr, so I don't know if avr is doing something like this (starting function with r32 == r28) always, or always for functions that require frame pointer, conditionally only for some CPUs, ... If it is always that way, you might want to consider just in some backend initialization that is run after init_alias_target call change this_target_rtl-x_static_reg_base_value[STACK_POINTER_REGNUM] to this_target_rtl-x_static_reg_base_value[FRAME_POINTER_REGNUM] (or vice versa), so that the RTL alias analysis doesn't disambiguate r28 from r32 based MEM accesses. Or a target hook somewhere in init_alias_analysis, or #define FIND_BASE_TERM(X) avr_find_base_term (X) where that function would return under the conditions where body starts with r32 == r28 would if (REG_P (x) REGNO (x) == STACK_POINTER_REGNUM) return find_base_term (frame_pointer_rtx); else return NULL_RTX;
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-20 06:54:00 UTC --- FIND_BASE_TERM is actually supposed just an alternate rtx expression, not its find_base_term value, so something like (perhaps with more conditions, when r28 is never equal to r32 in the body or r32 isn't initialized from r28, it doesn't need to be done): if (reload_completed frame_pointer_needed REG_P (x) REGNO (x) == STACK_POINTER_REGNUM) return frame_pointer_rtx; return NULL_RTX;
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-27 09:59:55 UTC --- Candidate for downgrading again if only avr-* is affected.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.2 |4.6.3 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-26 17:13:44 UTC --- GCC 4.6.2 is being released.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2011-09-11
15:25:10 UTC ---
Already wrong in the .expand dump:
;; MEM[(volatile unsigned int *)var][arg_1(D)] ={v} v_2;
(insn 9 8 10 (set (reg:DI 63)
(sign_extend:DI (reg/v:SI 60 [ argD.1604 ]))) t.c:6 -1
(nil))
(insn 10 9 11 (set (reg/f:DI 64)
(symbol_ref:DI (var) var_decl 0x7f4b8054f140 var)) t.c:6 -1
(nil))
(insn 11 10 0 (set (mem/s:SI (plus:DI (mult:DI (reg:DI 63)
(const_int 4 [0x4]))
(reg/f:DI 64)) [2 varD.1603 S4 A32])
(reg/v:SI 59 [ vD.1607 ])) t.c:6 -1
(nil))
It seems to me that the MEM in insn 11 should be mem/s/v.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2011-09-11 15:46:22 UTC --- (In reply to comment #8) Already wrong in the .expand dump: This comment somehow ended up in the wrong PR. It should be in bug 50078.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-08-15 08:07:29 UTC --- (In reply to comment #5) Sounds like some of the latent RTL alias issues we have with regarding to find_base_value and friends (see some i?86 bugreport I fail to remember right now). You mean PR49330?
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-15 11:05:08 UTC --- (In reply to comment #6) (In reply to comment #5) Sounds like some of the latent RTL alias issues we have with regarding to find_base_value and friends (see some i?86 bugreport I fail to remember right now). You mean PR49330? Yes.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|[avr]: DSE: wrong code for |[4.6/4.7 Regression] DSE: |gcc.dg/torture/pta-ptrarith |wrong code for |-3.c|gcc.dg/torture/pta-ptrarith ||-3.c --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-14 09:52:28 UTC --- Sounds like some of the latent RTL alias issues we have with regarding to find_base_value and friends (see some i?86 bugreport I fail to remember right now).
