[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So the question becomes do we care about this look if 
-fno-tree-loop-distribute-patterns  is added?  Anyways we are able to detect
the loop is a memset for a while now and then expand that to have no xor inside
the loop.

[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

[uros at kss-loka dot si]

------- Comment #6 from uros at kss-loka dot si  2005-10-28 06:05 -------
(In reply to comment #5)
> The realy problem here is that the xor is produced after reload and is really
> only done on some x86 targets.
> 
This happens in following peephole2 pattern:

;; Don't move an immediate directly to memory when the instruction
;; gets too big.
(define_peephole2
  [(match_scratch:SI 1 "r")
   (set (match_operand:SI 0 "memory_operand" "")
        (const_int 0))]
  "! optimize_size
   && ! TARGET_USE_MOV0
   && TARGET_SPLIT_LONG_MOVES
   && get_attr_length (insn) >= ix86_cost->large_insn
   && peep2_regno_dead_p (0, FLAGS_REG)"
  [(parallel [(set (match_dup 1) (const_int 0))
              (clobber (reg:CC FLAGS_REG))])
   (set (match_dup 0) (match_dup 1))]
  "")

The problem is, that peephole2 optimizations happens very late, and no further
RTL pass can eliminate redundant loads.

Do we need a post-peephole2 gcse pass? :)


-- 


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

[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2005-10-27 17:21 -------
The realy problem here is that the xor is produced after reload and is really
only done on some x86 targets.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-10-27 17:21:09
               date|                            |


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

[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

[gj at pointblue dot com dot pl]

------- Additional Comments From gj at pointblue dot com dot pl  2005-02-12 16:39 -------
that would be great if it will happend for 4.0. 
My bug here acctualy has two sides than. First gcc fails to trace register 
value that doesn't change and thus does not require to be cleared on every 
loop. Secondly also loop vectorizer fails to produce vector code, but that 
wasn't my initial problem anyway, just a second thought. 
 
thanks. 

-- 


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

[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

[dorit at il dot ibm dot com]

------- Additional Comments From dorit at il dot ibm dot com  2005-02-12 16:35 -------
We fail to vectorize with:
wagi.cc:43: note: not vectorized: unhandled data ref: D.31081_39 = this_3->wagi
wagi.cc:43: note: bad data references.

The loop in question looks like this:

  # i_1 = PHI <i_43(8), 0(7)>;
<L3>:;
  D.31081_39 = this_3->wagi;
  D.31082_40 = i_1 * 8;
  D.31083_41 = (double *) D.31082_40;
  D.31084_42 = D.31081_39 + D.31083_41;
  *D.31084_42 = 0.0;
  i_43 = i_1 + 1;
  if (synapsy_2 > i_43) goto <L16>; else goto <L5>;

<L16>:;
  goto <bb 3> (<L3>);

If the invariant expr 'D.31081_39 = this_3->wagi;' was taken out of loop, I 
think we would have vectorized it. 

-- 


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

[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

[gj at pointblue dot com dot pl]

------- Additional Comments From gj at pointblue dot com dot pl  2005-02-12 15:46 -------
I thought that -mtune=pentium3 should get him enough hints to use sse. Some 
warning would be great than if what you say is true about -ftree-vectorize! 
 
Besides, -msse doesn't turn on vectorization here either. But it should 
probably. That would do 2 doubles cleared at one shot, rather than using 
integer twice it could be cleared using mmx or sse registers. 

-- 


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

[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

[phython at gcc dot gnu dot org]

------- Additional Comments From phython at gcc dot gnu dot org  2005-02-12 15:39 -------
 -ftree-vectorize doesn't do anything here as -msse{,2} hasn't been specified.

-- 


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

[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target
           Keywords|                            |missed-optimization


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