[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 --- Comment #10 from sameerad at gcc dot gnu.org --- Yes, it can be marked as fixed. Thanks!
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 --- Comment #8 from sameerad at gcc dot gnu.org --- Author: sameerad Date: Tue Oct 30 10:59:37 2018 New Revision: 265618 URL: https://gcc.gnu.org/viewcvs?rev=265618=gcc=rev Log: Fixes bug 87330 by invoking df_note_add_problem to recompute REG_DEAD and REG_UNUSED notes before analysis. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/falkor-tag-collision-avoidance.c
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 --- Comment #6 from sameerad at gcc dot gnu.org --- Created attachment 44814 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44814=edit the regrename pass does not rename the registers which are in notes, because of which the REG_DEAD note had previous regname, which caused conflicting information generated for tag collision pass. It is better to do it in regrename_do_replace instead while regrename_analyze, because the note information does not really contribute into the regrename analysis, hence need not be added in the def-use chains that are computed. regrename_do_replace is where the decision to finally rename the register is made - where the note can be altered with new regname. Other notes need not be changed, as they don't hold renamed register information.
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 --- Comment #5 from sameerad at gcc dot gnu.org --- The original regrename pass is renaming the register x19 to x25, however, the expr_list which holds the dead register information is not updated accordingly. Hence, there is a conflict of register names when same information is accessed again by tag collision pass. The fix is under testing.
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 --- Comment #4 from sameerad at gcc dot gnu.org --- I am having a look at this issue.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 sameerad at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |sameerad at gcc dot gnu.org --- Comment #14 from sameerad at gcc dot gnu.org --- Assigned to myself.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #10 from sameerad at gcc dot gnu.org --- > subus: >ldr w0, [w0] >add w0, w0, w0, lsr #16 >uxth w0, w0 >ret This is interesting way in which load store combining can be enhanced further. I will try to figure out if this can be integrated in my current implementation. Thanks Richard.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #8 from sameerad at gcc dot gnu.org --- Currently, we are not planning to restrict load/store merging to specific cases. Restricted merging of loads and stores is already handled by GIMPLE store-merging pass. We are combining loads/stores, and then generating extract instructions with appropriate sign/zero extensions. W.r.t codesize, it is definitely expensive, and should be avoided. However, for performance, we want to experiment.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #5 from sameerad at gcc dot gnu.org --- The gimple store merging pass performs load/store merging only if the LHS is memory or constant. I am also working on the GIMPLE pass which will enhance this to merge other stores as well. However, wanted to do the performance measurement, that is why using the peephole2 pass.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #2 from sameerad at gcc dot gnu.org --- Ramana, it is another peephole that I am trying to explore for falkor. It combines loads/stores of shorter types (QI/HI/SI) into single load/store of larger type (SI/DI).
[Bug target/86209] New: Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
Bug ID: 86209
Summary: Peephole does not happen because the type of zero/sign
extended operands is not the same.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sameerad at gcc dot gnu.org
Target Milestone: ---
While implementing peephole2 for combining shorter types loads/stores into
larger type load/store, following testcase was found for aarch64 for which
peephole does not happen because the type of zero/sign extended operands is not
the same.
Test program:
unsigned short
subus (unsigned short *array)
{
return array[0] + array[1];
}
Expander generated RTL:
(insn 6 3 7 2 (set (reg:HI 96)
(mem:HI (reg/v/f:DI 94 [ array ]) [1 *array_4(D)+0 S2 A16]))
(nil))
(insn 7 6 8 2 (set (reg:HI 97)
(mem:HI (plus:DI (reg/v/f:DI 94 [ array ])
(const_int 2 [0x2])) [1 MEM[(short unsigned int *)array_4(D) +
2B]+0 S2 A16]))
(nil))
(insn 8 7 9 2 (set (reg:SI 99)
(subreg:SI (reg:HI 97) 0))
(nil))
(insn 9 8 10 2 (set (reg:SI 98)
(plus:SI (subreg:SI (reg:HI 96) 0)
(reg:SI 99)))
(expr_list:REG_EQUAL (plus:SI (subreg:SI (reg:HI 96) 0)
(subreg:SI (reg:HI 97) 0))
(nil)))
The combiner combines insn 7 and 8 to generate zero extension to SI mode.
(insn 8 7 9 2 (set (reg:SI 99 [ MEM[(short unsigned int *)array_4(D) + 2B] ])
(zero_extend:SI (mem:HI (plus:DI (reg/v/f:DI 94 [ array ])
(const_int 2 [0x2])) [1 MEM[(short unsigned int
*)array_4(D) + 2B]+0 S2 A16]))) {*zero_extendhisi2_aarch64}
(expr_list:REG_DEAD (reg/v/f:DI 94 [ array ])
(nil)))
The reload pass removes SUBREGs, which holds information about desired type,
because of which HImode regs are zero extended to DImode.
(insn 8 7 6 2 (set (reg:SI 1 x1 [orig:99 MEM[(short unsigned int *)array_4(D) +
2B] ] [99])
(zero_extend:SI (mem:HI (plus:DI (reg/v/f:DI 0 x0 [orig:94 array ]
[94])
(const_int 2 [0x2])) [1 MEM[(short unsigned int
*)array_4(D) + 2B]+0 S2 A16]))) {*zero_extendhisi2_aarch64}
(nil))
(insn 6 8 9 2 (set (reg:DI 0 x0)
(zero_extend:DI (mem:HI (reg/v/f:DI 0 x0 [orig:94 array ] [94]) [1
*array_4(D)+0 S2 A16]))) {*zero_extendhidi2_aarch64}
(nil))
(insn 9 6 14 2 (set (reg:SI 0 x0 [98])
(plus:SI (reg:SI 0 x0 [orig:96 *array_4(D) ] [96])
(reg:SI 1 x1 [orig:99 MEM[(short unsigned int *)array_4(D) + 2B] ]
[99]))){*addsi3_aarch64}
(nil))
(insn 14 9 15 2 (set (reg/i:HI 0 x0)
(reg:HI 0 x0 [98])) {*movhi_aarch64}
(nil))
(insn 15 14 17 2 (use (reg/i:HI 0 x0))
(nil))
(note 17 15 18 NOTE_INSN_DELETED)
(note 18 17 0 NOTE_INSN_DELETED)
Now as both memory accesses have different extended types, they cannot be
combined by peephole.
Because of this, even when sched_fusion has brought the loads/stores closer,
they cannot be merged.
[Bug target/51162] [4.7 Regression] ICE: segfault in dump_gimple_call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51162 sameerad at gcc dot gnu.org changed: What|Removed |Added CC||sameerad at gcc dot gnu.org --- Comment #2 from sameerad at gcc dot gnu.org 2011-12-15 09:31:10 UTC --- Fixed on trunk. - Sameera D.
