[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&root=gcc&view=rev Log: Fixes bug 87330 by invoking df_note_add_pr

[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&action=edit the regrename pass does not rename the registers which are in notes, because of which the R

[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

[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

[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 tr

[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

[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

[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.

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

[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