[Bug tree-optimization/49695] conditional moves for stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |12.0 Known to work||12.1.0 --- Comment #4 from Andrew Pinski --- On x86_64 with AVX2, and masked stores, GCC 12 is able to vectorize this loop just fine. On aarch64 with SVE2, GCC 12 is also able to vectorize the loop just fine too. I am just going to close as fixed.
[Bug tree-optimization/49695] conditional moves for stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization CC||pinskia at gcc dot gnu.org Severity|normal |enhancement
[Bug tree-optimization/49695] conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695
--- Comment #3 from revital.eres at linaro dot org 2011-07-10 13:41:07 UTC ---
> > the memory location we write to.
> hmmm... after reading Sebastian Pop's paper from the last summit ("Improving
> GCC’s auto-vectorization with if-conversion and loop
> flattening for AMD’s Bulldozer processors") it's seems that we need to grantee
> that point1->arr[i].val is writable when the condition is false which we can
> not prove in this case. So that's not a bug, I apologize for the noise.
Continuing reading the paper I see that under the 'If-conversion without
restrictions' section there is a technique that allows to apply if-conversion
in the above case by writing to artificial object that has been
created by the compiler when the condition is false. I assume this method is
not implemented in trunk yet.
[Bug tree-optimization/49695] conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695
--- Comment #2 from revital.eres at linaro dot org 2011-07-10 12:50:31 UTC ---
(In reply to comment #0)
> for (i = 0; i < point1->len; i++)
> {
> if (point1->arr[i].val)
> {
> point1->arr[i].val ^= (unsigned long long) res;
> }
> }
> For the above loop if-conversion is not been done in the tree level (compiled
> with trunk -r176116). Seemingly this case is similar to the one in PR27313.
> When using -ftree-loop-if-convert-stores I get 'tree could trap...' message
> although I'm not sure why as there is a read in every iteration of the loop to
> the memory location we write to.
hmmm... after reading Sebastian Pop's paper from the last summit ("Improving
GCC’s auto-vectorization with if-conversion and loop
flattening for AMD’s Bulldozer processors") it's seems that we need to grantee
that point1->arr[i].val is writable when the condition is false which we can
not prove in this case. So that's not a bug, I apologize for the noise.
[Bug tree-optimization/49695] conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695 --- Comment #1 from revital.eres at linaro dot org 2011-07-10 10:05:07 UTC --- Created attachment 24730 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24730 Testcase which contains the loop
