[Bug tree-optimization/20517] bit shift/mask optimization potential

[Bug tree-optimization/20517] bit shift/mask optimization potential

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |roger at nextmovesoftware dot com
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.6.4

--- Comment #8 from Roger Sayle <roger at nextmovesoftware dot com> ---
GCC generates code without shifts for all the examples in comment #4, since
around version 4.6.4.  The "((x&0xf0)>>4) == 1" of the original, is now
canonicalized to "((x>>4)&0xf) == 1" at the tree-level (to minimize the size of
immediate constants).  Whether ((x>>C1)&C2)==C3 is more/less efficient than
(x&C4)==C5, where C4=C2<<C1 and C5=C3<<C1, depends upon the target, so this
decision is made in the RTL optimizers, as explained in the PR's comments.

[Bug tree-optimization/20517] bit shift/mask optimization potential

[zsojka at seznam dot cz]

------- Comment #7 from zsojka at seznam dot cz  2010-09-09 17:52 -------
(In reply to comment #5)
> Yes, please, and assign to me (working on a simplify_comparison fix for that).
> 

Opened PR45617, attached your patch with results (bootstrapped fine,
optimisation seems to work). Thank you for having a look!


-- 


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

[Bug tree-optimization/20517] bit shift/mask optimization potential

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2010-09-08 18:10 -------
Created an attachment (id=21744)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21744&action=view)
gcc46-pr20517.patch

Untested patch.


-- 


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

[Bug tree-optimization/20517] bit shift/mask optimization potential

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2010-09-08 16:19 -------
Yes, please, and assign to me (working on a simplify_comparison fix for that).


-- 


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

[Bug tree-optimization/20517] bit shift/mask optimization potential

[zsojka at seznam dot cz]

------- Comment #4 from zsojka at seznam dot cz  2010-09-07 21:50 -------
However, this optimization in RTL doesn't happen in all cases. For x86_64-linux
(with or without -m32):

----- testcase.c -----
_Bool foo(unsigned i)
{
        return (i >> 5) > 10;
}

_Bool bar(unsigned i)
{
        return i > (10 << 5);
}

int fooi(unsigned i)
{
        return (i >> 5) > 10;
}

int bari(unsigned i)
{
        return i > (10 << 5);
}
----------------------

Compiled with:
$ gcc-4.6.0-pre9999 tst6.c -O3 -S -m32 -fomit-frame-pointer
(svn r162190)

Results in:
foo:
        movl    4(%esp), %eax
        shrl    $5, %eax
        cmpl    $10, %eax
        seta    %al
        ret
bar:
        cmpl    $320, 4(%esp)
        seta    %al
        ret
fooi:
        movl    4(%esp), %eax
        shrl    $5, %eax
        cmpl    $10, %eax
        seta    %al
        movzbl  %al, %eax
        ret
bari:
        xorl    %eax, %eax
        cmpl    $320, 4(%esp)
        seta    %al
        ret

When compiled with -m64 it gets a bit better because parameter is in edi
instead of in stack, but the problem is still there. Should I open separate PR
for this?


-- 

zsojka at seznam dot cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zsojka at seznam dot cz


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

[Bug tree-optimization/20517] bit shift/mask optimization potential

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-04-23 18:01 -------
For PowerPC, either way is implemented the same in that it uses the same two
instructions (though with different operands).


-- 


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

[Bug tree-optimization/20517] bit shift/mask optimization potential

[phython at gcc dot gnu dot org]

------- Additional Comments From phython at gcc dot gnu dot org  2005-07-23 21:05 -------
 The condition around fold-const:9302 can be generalized to deal with this case.


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


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

[Bug tree-optimization/20517] bit shift/mask optimization potential

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-17 17:21 -------
Confirmed, but this is already done on the RTL level.  So the assembler looks same for what you 
recomend and what is produced already.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |19986
              nThis|                            |
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
          Component|middle-end                  |tree-optimization
     Ever Confirmed|                            |1
           Keywords|                            |TREE
   Last reconfirmed|0000-00-00 00:00:00         |2005-03-17 17:21:20
               date|                            |
            Version|unknown                     |4.1.0


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