https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|ubizjak at gmail d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #16 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #15)
> FTR, clobbers are already marked as having side effects:
Oops, I got the logic wrong. Please disregard this comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #15 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to Eric Botcazou from comment #12)
>
> > So what about just marking inline asms with memory clobber as having side
> > effects?
> I guess this would wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #14 from Richard Sandiford ---
ISTM that the problem is that cselib doesn't consider:
(clobber (mem:BLK (scratch)))
to be a read from memory (unlike note_uses, which gets this right). cselib
instead assumes that the SET_SRC of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #13 from Uroš Bizjak ---
(In reply to Eric Botcazou from comment #12)
> So what about just marking inline asms with memory clobber as having side
> effects?
I guess this would work, the compiler must preserve side effects when
optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #12 from Eric Botcazou ---
> Later in the compilation pipeline, DCE removes insns 6 and 8 as dead code,
> leaving:
>
> _.c.331r.cmpelim:
>
>10: {x1:SI=asm_operands;clobber [scratch];}
>12: {x3:SI=asm_operands;clobber [scrat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #11 from Uroš Bizjak ---
(In reply to Eric Botcazou from comment #10)
> Is it really invalid to perform CSE on val though?
Later in the compilation pipeline, DCE removes insns 6 and 8 as dead code,
leaving:
_.c.331r.cmpelim:
10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #10 from Eric Botcazou ---
Is it really invalid to perform CSE on val though?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
Uroš Bizjak changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #8 from Uroš Bizjak ---
Compiling the testcase for aarch64-linux-gnu (-O2 -funroll-all-loops) still
performs CSE, despite the patch:
_.c.325r.reload:
6: {x0:SI=asm_operands;clobber [scratch];}
8: {x2:SI=asm_operands;clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
Uroš Bizjak changed:
What|Removed |Added
Keywords||patch
--- Comment #7 from Uroš Bizjak --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #4 from Andrew Pinski ---
Looks like postreload_cse is causing the issue ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #3 from Linus Torvalds ---
(In reply to Andrew Pinski from comment #1)
> I suspect without an input, the cse will happen as there is no other writes
> in the loop.
Yes, it looks to me like the CSE simply didn't think of the memory c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Component|middle-en
16 matches
Mail list logo