[Bug c++/27212] New: Altivec Comparison Peephole Bug

[Bug c++/27212] New: Altivec Comparison Peephole Bug

[ben at shellandslate dot com]

Given the Altivec function:

vector unsigned short peepholebug(vector unsigned short a, vector unsigned
short b) {
        vector unsigned short mask = (vector unsigned short)vec_cmplt(a, b);

        if (vec_all_ge(a, b))   return a;

        return mask;
        }

XCode 2.2.1 / gcc 4.0 on PowerMac G5 generates ( with optimizer set to -os):

mfspr r0,256
stw r0,-8(r1)
oris r0,r0,0x8000
mtspr 256,r0
vcmpgtuh. v0,v3,v2
vcmpgtuh v0,v3,v2
beq cr6,L99
vor v2,v0,v0
lwz r12,-8(r1)
mtspr 256,r12
blr

Note the second "vcmpgtuh" instruction, which is completely superfluous. The
peephole optimizer should recognize this situation and remove the instruction.
(I've filed a bug with Apple; #4519214.)


-- 
           Summary: Altivec Comparison Peephole Bug
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ben at shellandslate dot com
 GCC build triplet: 4.0.0
  GCC host triplet: 4.0.0
GCC target triplet: 4.0.0


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

[Bug c++/27212] Altivec Comparison Peephole Bug

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-04-19 15:03 -------
This already has been fixed at least for 4.1.0 though it is still a regression
on the 4.0 branch.

Anyways this is a dup of bug 22077 which I filed back when I first heard about
this bug from some Apple employees.

*** This bug has been marked as a duplicate of 22077 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug target/27212] vec_cmplt followed by a vec_all_ge, gives two vcmpgtuh instructions

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-04-19 16:49 -------
Actually this is a different issue than I orginally thought (just waking up).
(insn:TI 16 9 14 (parallel [
            (set (reg:CC 74 6)
                (unspec:CC [
                        (reg/v:V8HI 77 0 [orig:126 b ] [126])
                        (reg/v:V8HI 78 1 [orig:124 a ] [124])
                        (symbol_ref:SI ("*vcmpgtuh."))
                    ] 173))
            (clobber (reg:V8HI 90 13))
        ]) 666 {altivec_predicate_v8hi} (nil)
    (nil))

(insn 14 16 20 (set (reg:V8HI 77 0 [orig:121 D.1927 ] [121])
        (unspec:V8HI [
                (reg/v:V8HI 77 0 [orig:126 b ] [126])
                (reg/v:V8HI 78 1 [orig:124 a ] [124])
            ] 58)) 531 {altivec_vcmpgtuh} (nil)
    (nil))


The instructions are not even alike in RTL.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|RESOLVED                    |UNCONFIRMED
          Component|c++                         |target
  GCC build triplet|4.0.0                       |
   GCC host triplet|4.0.0                       |
 GCC target triplet|4.0.0                       |powerpc-*-*
         Resolution|DUPLICATE                   |
            Summary|Altivec Comparison Peephole |vec_cmplt followed by a
                   |Bug                         |vec_all_ge, gives two
                   |                            |vcmpgtuh instructions


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

[Bug target/27212] vec_cmplt followed by a vec_all_ge, gives two vcmpgtuh instructions

[ben at shellandslate dot com]

------- Comment #3 from ben at shellandslate dot com  2006-04-19 20:20 -------
It's true that the instructions are not identical (the first sets the condition
register, the second doesn't.) But the second still duplicates work already
performed, and should be removed. (The two instructions are sometimes generated
in reverse order from similar source code, but the same principle applies.)
I've verified with assembly that removing the second instruction has no effect
on the program behavior, except to make it faster. :)


-- 


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

[Bug target/27212] vec_cmplt followed by a vec_all_ge, gives two vcmpgtuh instructions

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-04-22 18:36 -------
Confirmed.  Note I was talking about the internal representation in that, the
instructions are not modeled correctly.


-- 

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         |2006-04-22 18:36:49
               date|                            |


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

[Bug target/27212] vec_cmplt followed by a vec_all_ge, gives two vcmpgtuh instructions

[bonzini at gnu dot org]

------- Comment #5 from bonzini at gnu dot org  2006-06-09 08:15 -------
I'll give it a shot.  If combine could, well, combine the two instructions, it
would be quite easy to make a patch, and it would remove some most hackish
aspects of the Altivec implemention.


-- 


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

[Bug target/27212] vec_cmplt followed by a vec_all_ge, gives two vcmpgtuh instructions

[bonzini at gnu dot org]

------- Comment #6 from bonzini at gnu dot org  2009-02-24 09:01 -------
CCing Michael as he's doing Altivec/VSX work.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |meissner at gcc dot gnu dot
                   |                            |org


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