https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
John Zwinck changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
--- Comment #6 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #5)
> I'm sure a microbench would show that makes a difference.
A micro-benchmark on skylake with -march=native (using just -mavx2 is worse for
gcc without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
--- Comment #5 from rguenther at suse dot de ---
On Tue, 2 May 2017, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
>
> --- Comment #4 from Marc Glisse ---
> Cool, that matches pretty much exactly the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
--- Comment #4 from Marc Glisse ---
Cool, that matches pretty much exactly the analysis I had posted on
stackoverflow ;-)
A separate issue from whether we can somehow propagate the alignment
information is what we do without the alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
--- Comment #3 from John Zwinck ---
I'm aware of the workaround using __builtin_assume_aligned() - you can see I
formulated an equivalent but pure C++ workaround using alignas() in the
aforementioned Stack Overflow post. But 99% of users won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
--- Comment #2 from Richard Biener ---
Ok, the reason is that the actual memory reference does not expose this
alignment.
The vectorizer sees
MEM[(const value_type &)v2_7(D)][_1]
unit size
align 64 symtab 0 alias set -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
