[Bug tree-optimization/65930] Reduction with sign-change not handled

2019-06-12 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

--- Comment #15 from rguenther at suse dot de  ---
On Wed, 12 Jun 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #14 from Jakub Jelinek  ---
> Couldn't this be done during ifcvt on the if (LOOP_VECTORIZED ()) copy of the
> loop?

Yes, some sanitizing of reductions could be done here.  OTOH in
theory the sanitizing can be done "transparently" in the vectorizer,
just the book-keeping is somewhat awkward at the moment.

[Bug tree-optimization/65930] Reduction with sign-change not handled

2019-06-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
Couldn't this be done during ifcvt on the if (LOOP_VECTORIZED ()) copy of the
loop?

[Bug tree-optimization/65930] Reduction with sign-change not handled

2019-05-21 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

Richard Biener  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #13 from Richard Biener  ---
*** Bug 90554 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/65930] Reduction with sign-change not handled

2019-04-10 Thread tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

--- Comment #12 from Tamar Christina  ---
> If you have some clever ideas make sure to outline a patch
> before finalizing it so you won't be disappointed by negative feedback ;)

I'll be sure to do that with this and the other changes I intend to tackle! :)

[Bug tree-optimization/65930] Reduction with sign-change not handled

2019-04-10 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

--- Comment #11 from rguenther at suse dot de  ---
On Tue, 9 Apr 2019, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930
> 
> Tamar Christina  changed:
> 
>What|Removed |Added
> 
>  CC||tnfchris at gcc dot gnu.org
> 
> --- Comment #10 from Tamar Christina  ---
> Hi Richard,
> 
> Do you still plan on working on this? Otherwise I'd like to add it to my list
> of things to do for GCC 10.

I failed to come up with a "nice" way to handle this - everything I
did inside the vectorizer turned out to be a hack (and I don't like
hacks).  If you have some clever ideas make sure to outline a patch
before finalizing it so you won't be disappointed by negative feedback ;)

[Bug tree-optimization/65930] Reduction with sign-change not handled

2019-04-09 Thread tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #10 from Tamar Christina  ---
Hi Richard,

Do you still plan on working on this? Otherwise I'd like to add it to my list
of things to do for GCC 10.

[Bug tree-optimization/65930] Reduction with sign-change not handled

2018-12-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

--- Comment #9 from Richard Biener  ---
(In reply to Richard Biener from comment #8)
> Note the tricky part is not so much the loop vectorization (teaching
> reduction path support about the conversion is not difficult with the twist
> that we
> need to handle conversions as reduction code...) but the vector epilogue
> which
> does the lane reduction in signed int exposing undefined overflow issues.
> 
> Of course the vectorizer doesn't seem to care here anyways and vectorizes
> signed integer reductions without caring for that specific issue...
> 
> In general feeding the conversion as reduction operation through the
> vectorizer
> is a bit awkward so pattern-recognizing this as
> 
>   int tem = (int)x[i];
>   sum += tem;
> 
> would be easier given we seem to ignore the undefined overflow issues...

but pattern recog runs after reduction detection (and that's not easy to
change).

[Bug tree-optimization/65930] Reduction with sign-change not handled

2018-12-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

--- Comment #8 from Richard Biener  ---
Note the tricky part is not so much the loop vectorization (teaching reduction
path support about the conversion is not difficult with the twist that we
need to handle conversions as reduction code...) but the vector epilogue which
does the lane reduction in signed int exposing undefined overflow issues.

Of course the vectorizer doesn't seem to care here anyways and vectorizes
signed integer reductions without caring for that specific issue...

In general feeding the conversion as reduction operation through the vectorizer
is a bit awkward so pattern-recognizing this as

  int tem = (int)x[i];
  sum += tem;

would be easier given we seem to ignore the undefined overflow issues...

[Bug tree-optimization/65930] Reduction with sign-change not handled

2018-12-12 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed|2015-04-29 00:00:00 |2018-12-12
 CC||ktkachov at gcc dot gnu.org

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Clang vectorises both examples currently (for aarch64 at least)

[Bug tree-optimization/65930] Reduction with sign-change not handled

2018-12-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

Richard Biener  changed:

   What|Removed |Added

 CC||jiangning.liu@amperecomputi
   ||ng.com

--- Comment #6 from Richard Biener  ---
*** Bug 88459 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/65930] Reduction with sign-change not handled

2017-12-05 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

--- Comment #5 from rguenther at suse dot de  ---
On December 5, 2017 4:23:17 PM GMT+01:00, "sergey.shalnov at intel dot com"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930
>
>sergey.shalnov at intel dot com changed:
>
>   What|Removed |Added
>
>CC||sergey.shalnov at intel dot com
>
>--- Comment #4 from sergey.shalnov at intel dot com ---
>Richard,
>I can confirm that the issue exists and it can be solved by make data
>types of
>accumulator and equation equal.
>As I can see you propose to introduce intermediate internal accumulator
>in
>uint32 type and store it into accumulator (int) later. Please correct
>me if I'm
>wrong.
>
>Anyway, may I, please, propose a bit simpler way to solve the issue?
>In GIMPLE statement we have (in the place of reduction
>tree-vect=loop.c:2877):
>"sum_12 = (int) _6;"
>
>I believe the issue disappears if we change it to:
>"sum_12 = _6;"
>
>I'm not sure but, if I remember correctly, the C standard treat these
>types
>(uint->int) casting as "undefined behavior". In this case, the compiler
>can do
>this type cast(it might be under some command line switches).
>
>What do you think, could it help?

This is what the patch tries to do transparent in the vectorizer. Doing it
generally isn't valid.

[Bug tree-optimization/65930] Reduction with sign-change not handled

2017-12-05 Thread sergey.shalnov at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

sergey.shalnov at intel dot com changed:

   What|Removed |Added

 CC||sergey.shalnov at intel dot com

--- Comment #4 from sergey.shalnov at intel dot com ---
Richard,
I can confirm that the issue exists and it can be solved by make data types of
accumulator and equation equal.
As I can see you propose to introduce intermediate internal accumulator in
uint32 type and store it into accumulator (int) later. Please correct me if I'm
wrong.

Anyway, may I, please, propose a bit simpler way to solve the issue?
In GIMPLE statement we have (in the place of reduction tree-vect=loop.c:2877):
"sum_12 = (int) _6;"

I believe the issue disappears if we change it to:
"sum_12 = _6;"

I'm not sure but, if I remember correctly, the C standard treat these types
(uint->int) casting as "undefined behavior". In this case, the compiler can do
this type cast(it might be under some command line switches).

What do you think, could it help?
Sergey

[Bug tree-optimization/65930] Reduction with sign-change not handled

2017-11-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

--- Comment #3 from Richard Biener  ---
Created attachment 42730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42730=edit
WIP patch

What I have sitting in my tree.  Steps to make this clean is

 1) refactor things to record the original scalar reduction code somewhere
(add place in stmt vinfo?)
 2) make it less awkward ...
 3) somehow merge SLP reduction detection with the more generic path detection
(the cases that interest us are SLP reductions, I think the case with just
a path is handled already)

Oh, the patch exposes lots of ICEs, I didn't really finish it.

[Bug tree-optimization/65930] Reduction with sign-change not handled

2015-04-29 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-04-29
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Mine.


[Bug tree-optimization/65930] Reduction with sign-change not handled

2015-04-29 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930

--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
More correct would be to replace the reduction in sum with one using an
unsigned int type.  Not sure where this kind of transform would fit best,
but as it's an enablement for vectorization I suppose the vectorizer should
take care of that.