https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #19 from Richard Biener ---
Created attachment 51150
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51150=edit
patch
This is what I bootstrapped & tested on x86_64-unknown-linux-gnu. It causes
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #18 from Richard Biener ---
OTOH we call is_really_empty_class which for not trivially empty classes ends
up
walking all non-FIELD_DECL fields as well:
for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #16 from Richard Biener ---
This has the situation improved but the aggregate copy and one dependent store
are still not moved (so not fixed).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #15 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9f34b780b0461ec7b2b2defe96e44ab616ea2aa3
commit r12-2097-g9f34b780b0461ec7b2b2defe96e44ab616ea2aa3
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
Bug 99728 depends on bug 101293, which changed state.
Bug 101293 Summary: LIM ref canonicalization incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101293
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #14 from Richard Biener ---
With the hack and PR101293 fixed we're still left with
Memory reference 13: *d_28(D).lam1.v
Memory reference 14: VIEW_CONVERT_EXPR(*d_28(D).lam1)
because the access types are incompatible (v4df vs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #13 from Richard Biener ---
Created attachment 51100
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51100=edit
hack
The attached tries to rewrite the aggregate assignments into a load/store
sequence producing
_33 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #12 from Martin Reinecke ---
Any hope of addressing this for gcc 12?
I have a real-world test case where this effect causes roughly 15-20% slowdown,
and I expect that with the wider availability of std::simd types more people
will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #11 from rguenther at suse dot de ---
On Wed, 24 Mar 2021, kretz at kde dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
>
> --- Comment #10 from Matthias Kretz (Vir) ---
> Is this the same issue:
>
> struct A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #10 from Matthias Kretz (Vir) ---
Is this the same issue:
struct A {
double v;
};
struct B {
double v;
B& operator=(const B& rhs) {
v = rhs.v;
return *this;
}
};
// 10 loads & stores
void f(A& a, const A& b) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
13 matches
Mail list logo
