[Bug tree-optimization/32825] Reduction with nonzero start (arbitrary also) causes an extra add to happen

[Bug tree-optimization/32825] Reduction with nonzero start (arbitrary also) causes an extra add to happen

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32825

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-28
     Ever Confirmed|0                           |1

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-28 03:03:51 UTC ---
Even on x86, it is just as fast to generate {0,0,0,0} as it is {e,0,0,0}:
    movd    %edi, %xmm0
or:
    xorps    %xmm1, %xmm1
    movss    %xmm0, %xmm1
    movaps    %xmm1, %xmm0

[Bug tree-optimization/32825] Reduction with nonzero start (arbitrary also) causes an extra add to happen

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32825

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2012-01-28 00:00:00         |2021-7-18

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Clang actually does one extra thing of having 2 variables to carry the add
through the loop, one is {e, 0, 0, 0}.

Also Power has been enhanced such that creating {e, 0, 0, 0} is not as
expensive any more either.

[Bug tree-optimization/32825] Reduction with nonzero start (arbitrary also) causes an extra add to happen

[dorit at gcc dot gnu dot org]

------- Comment #3 from dorit at gcc dot gnu dot org  2007-07-24 13:05 -------
(In reply to comment #1)
> ... We actually had both options in the vectorizer for a while
> (guarded by ADJUST_IN_EPILOG hard-coded #define), however we didn't know how to
> choose between the two options (cost wise), so we just arbitrarily chose one.
> Now that we're starting to build a cost model we may try to evaluate which of
> the two options to generate. 

for the record - this was the patch that removed the second option:

2007-04-18  Dorit Nuzman  <dorit@il.ibm.com>

        * tree-vect-transform.c (get_initial_def_for_reduction): Clean away
        the unused code for reduction without adjust-in-epilog to simplify the
        function.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32825

[Bug tree-optimization/32825] Reduction with nonzero start (arbitrary also) causes an extra add to happen

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-07-19 18:32 -------
> The problem is that often initializing a vector to {e, 0, 0, 0} is (much?) more
On SPU, it is not:

        cwd     $2,0($sp)
        shufb   $5,$3,$5,$2

vs:
        ori     $7,$3,0
        il      $5,0
...
        a       $8,$9,$7

Also it increases register pressure by long gating incomming argument.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32825

[Bug tree-optimization/32825] Reduction with nonzero start (arbitrary also) causes an extra add to happen

[dorit at gcc dot gnu dot org]

------- Comment #1 from dorit at gcc dot gnu dot org  2007-07-19 18:15 -------
...
> Though the last add is extra and does not need to be done, we can get rid of it
> by having vect_var_.36 being set initially to {e, 0, 0, 0} .

The problem is that often initializing a vector to {e, 0, 0, 0} is (much?) more
expensive than initializing a vector to {0, 0, 0, 0} and then adding e to the
final scalar result. We actually had both options in the vectorizer for a while
(guarded by ADJUST_IN_EPILOG hard-coded #define), however we didn't know how to
choose between the two options (cost wise), so we just arbitrarily chose one.
Now that we're starting to build a cost model we may try to evaluate which of
the two options to generate. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32825