public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/107263] New: Memcpy not elided when initializing struct
@ 2022-10-14 13:13 jmuizelaar at mozilla dot com
2022-10-14 15:45 ` [Bug tree-optimization/107263] " pinskia at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: jmuizelaar at mozilla dot com @ 2022-10-14 13:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107263
Bug ID: 107263
Summary: Memcpy not elided when initializing struct
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jmuizelaar at mozilla dot com
Target Milestone: ---
With the following code
struct Foo {
Foo* next;
char arr[580];
};
void ctx_push(Foo* f) {
Foo tmp = { f->next };
*f = tmp;
}
Clang is able to generate code that just memsets `arr`. GCC instead initializes
the entire struct on the stack and then copies it into `f`.
https://gcc.godbolt.org/z/Yzcbs4G71
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/107263] Memcpy not elided when initializing struct
2022-10-14 13:13 [Bug tree-optimization/107263] New: Memcpy not elided when initializing struct jmuizelaar at mozilla dot com
@ 2022-10-14 15:45 ` pinskia at gcc dot gnu.org
2022-10-17 7:43 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-14 15:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107263
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Keywords| |missed-optimization
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/107263] Memcpy not elided when initializing struct
2022-10-14 13:13 [Bug tree-optimization/107263] New: Memcpy not elided when initializing struct jmuizelaar at mozilla dot com
2022-10-14 15:45 ` [Bug tree-optimization/107263] " pinskia at gcc dot gnu.org
@ 2022-10-17 7:43 ` rguenth at gcc dot gnu.org
2022-10-17 13:28 ` jmuizelaar at mozilla dot com
2024-03-19 17:27 ` hiraditya at msn dot com
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-10-17 7:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107263
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-10-17
Version|unknown |13.0
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC| |jamborm at gcc dot gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. The frontend leaves us with
<<cleanup_point struct Foo tmp = {};>>;
<<cleanup_point <<< Unknown tree: expr_stmt
tmp.next = f->next >>>>>;
<<cleanup_point <<< Unknown tree: expr_stmt
(void) (*NON_LVALUE_EXPR <f> = *(const struct Foo &) &tmp) >>>>>;
and ESRA sees
<bb 2> :
tmp = {};
_1 = f_4(D)->next;
tmp.next = _1;
*f_4(D) = tmp;
tmp ={v} {CLOBBER(eol)};
return;
ESRA somewhat senselessly does
<bb 2> :
tmp = {};
tmp$next_8 = 0B;
_1 = f_4(D)->next;
tmp$next_9 = _1;
tmp.next = tmp$next_9;
*f_4(D) = tmp;
tmp ={v} {CLOBBER(eol)};
return;
it doesn't scalarize the array because that's too large. I would guess
that Clang doesn't split the initializer and thus its aggregate copy
propagation somehow manages to elide 'tmp'. We don't have a good
place to peform the desired optimization, certainly the split
initialization of 'tmp' complicates things.
In principle it would be SRAs job since I think it does most of the
necessary analysis, it just lacks knowledge on how to re-materialize
*f_4(D) efficiently at the point of the aggregate assignment?
It has
Candidate (2384): tmp
Too big to totally scalarize: tmp (UID: 2384)
Created a replacement for tmp offset: 0, size: 64: tmp$nextD.2425
Access trees for tmp (UID: 2384):
access { base = (2384)'tmp', offset = 0, size = 4736, expr = tmp, type = struct
Foo, reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read = 1,
grp_assignment_write = 1, grp_scalar_read = 0, grp_scalar_write = 0,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 0,
grp_unscalarizable_region = 0, grp_unscalarized_data = 1, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 0, grp_to_be_debug_replaced = 0}
* access { base = (2384)'tmp', offset = 0, size = 64, expr = tmp.next, type =
struct Foo *, reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read =
1, grp_assignment_write = 1, grp_scalar_read = 0, grp_scalar_write = 1,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 1,
grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0}
but it fails to record that for the size 4736 write there's a clear performed
that's cheaply to re-materialize (and no variables need to be created). SRA
could probably track writes from only constants that way, avoiding to create
scalar replacements.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/107263] Memcpy not elided when initializing struct
2022-10-14 13:13 [Bug tree-optimization/107263] New: Memcpy not elided when initializing struct jmuizelaar at mozilla dot com
2022-10-14 15:45 ` [Bug tree-optimization/107263] " pinskia at gcc dot gnu.org
2022-10-17 7:43 ` rguenth at gcc dot gnu.org
@ 2022-10-17 13:28 ` jmuizelaar at mozilla dot com
2024-03-19 17:27 ` hiraditya at msn dot com
3 siblings, 0 replies; 5+ messages in thread
From: jmuizelaar at mozilla dot com @ 2022-10-17 13:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107263
--- Comment #2 from Jeff Muizelaar <jmuizelaar at mozilla dot com> ---
Even for small arrays clang does a noticeably better job:
https://gcc.godbolt.org/z/4d3TjGazY
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/107263] Memcpy not elided when initializing struct
2022-10-14 13:13 [Bug tree-optimization/107263] New: Memcpy not elided when initializing struct jmuizelaar at mozilla dot com
` (2 preceding siblings ...)
2022-10-17 13:28 ` jmuizelaar at mozilla dot com
@ 2024-03-19 17:27 ` hiraditya at msn dot com
3 siblings, 0 replies; 5+ messages in thread
From: hiraditya at msn dot com @ 2024-03-19 17:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107263
AK <hiraditya at msn dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hiraditya at msn dot com
--- Comment #3 from AK <hiraditya at msn dot com> ---
Seems like a duplicate of #59863 ?
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-03-19 17:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-14 13:13 [Bug tree-optimization/107263] New: Memcpy not elided when initializing struct jmuizelaar at mozilla dot com
2022-10-14 15:45 ` [Bug tree-optimization/107263] " pinskia at gcc dot gnu.org
2022-10-17 7:43 ` rguenth at gcc dot gnu.org
2022-10-17 13:28 ` jmuizelaar at mozilla dot com
2024-03-19 17:27 ` hiraditya at msn dot com
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).