public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/94267] New: Missed folding of &TARGET_MEM_REF
@ 2020-03-23 8:17 rguenth at gcc dot gnu.org
2020-03-23 8:18 ` [Bug middle-end/94267] " rguenth at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-23 8:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94267
Bug ID: 94267
Summary: Missed folding of &TARGET_MEM_REF
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Seen in PR94266 IVOPTs can generate &TARGET_MEM_REF[ptr_1 + 0] which we
obviously should represent as plain ptr_1, possibly casted. Likewise
&TARGET_MEM_REF[ptr_1 + 4] should be canonicalized to &MEM_REF[ptr_1 + 4]
or even a POINTER_PLUS_EXPR.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/94267] Missed folding of &TARGET_MEM_REF
2020-03-23 8:17 [Bug middle-end/94267] New: Missed folding of &TARGET_MEM_REF rguenth at gcc dot gnu.org
@ 2020-03-23 8:18 ` rguenth at gcc dot gnu.org
2021-12-13 8:33 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-23 8:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94267
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
Last reconfirmed| |2020-03-23
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine, for GCC 11.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/94267] Missed folding of &TARGET_MEM_REF
2020-03-23 8:17 [Bug middle-end/94267] New: Missed folding of &TARGET_MEM_REF rguenth at gcc dot gnu.org
2020-03-23 8:18 ` [Bug middle-end/94267] " rguenth at gcc dot gnu.org
@ 2021-12-13 8:33 ` pinskia at gcc dot gnu.org
2023-09-25 21:04 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-13 8:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94267
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #0)
> Likewise
> &TARGET_MEM_REF[ptr_1 + 4] should be canonicalized to &MEM_REF[ptr_1 + 4]
> or even a POINTER_PLUS_EXPR.
We now canonicalized &MEM_REF[ptr_1 + 4] in gimple-fold to a POINTER_PLUS_EXPR.
I didn't handle &TARGET_MEM_REF though.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/94267] Missed folding of &TARGET_MEM_REF
2020-03-23 8:17 [Bug middle-end/94267] New: Missed folding of &TARGET_MEM_REF rguenth at gcc dot gnu.org
2020-03-23 8:18 ` [Bug middle-end/94267] " rguenth at gcc dot gnu.org
2021-12-13 8:33 ` pinskia at gcc dot gnu.org
@ 2023-09-25 21:04 ` pinskia at gcc dot gnu.org
2023-09-25 21:04 ` pinskia at gcc dot gnu.org
2023-09-26 6:53 ` rguenth at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-09-25 21:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94267
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=110702
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Right now we depend on not doing the folding, PR 110702.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/94267] Missed folding of &TARGET_MEM_REF
2020-03-23 8:17 [Bug middle-end/94267] New: Missed folding of &TARGET_MEM_REF rguenth at gcc dot gnu.org
` (2 preceding siblings ...)
2023-09-25 21:04 ` pinskia at gcc dot gnu.org
@ 2023-09-25 21:04 ` pinskia at gcc dot gnu.org
2023-09-26 6:53 ` rguenth at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-09-25 21:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94267
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> Right now we depend on not doing the folding, PR 110702.
Well rather we depend on not folding *(&TARGET_MEM_REF) ...
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/94267] Missed folding of &TARGET_MEM_REF
2020-03-23 8:17 [Bug middle-end/94267] New: Missed folding of &TARGET_MEM_REF rguenth at gcc dot gnu.org
` (3 preceding siblings ...)
2023-09-25 21:04 ` pinskia at gcc dot gnu.org
@ 2023-09-26 6:53 ` rguenth at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-09-26 6:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94267
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, yes .. &TARGET_MEM_REF is a LEA with a specific addressing mode. Folding
*&TARGET_MEM_REF would require us to verify the target can handle it (and avoid
PR110702 where it's fix was really the only sensible thing I could think of).
We _might_ want to fold &TARGET_MEM_REF[0 + ..] to '..', but the whole point
of [&]TARGET_MEM_REF is to keep it until RTL expansion. Unless the folding
is degenerate of course.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-09-26 6:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-23 8:17 [Bug middle-end/94267] New: Missed folding of &TARGET_MEM_REF rguenth at gcc dot gnu.org
2020-03-23 8:18 ` [Bug middle-end/94267] " rguenth at gcc dot gnu.org
2021-12-13 8:33 ` pinskia at gcc dot gnu.org
2023-09-25 21:04 ` pinskia at gcc dot gnu.org
2023-09-25 21:04 ` pinskia at gcc dot gnu.org
2023-09-26 6:53 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).