[Bug middle-end/56924] Folding of checks into a range check should check upper boundary

[Bug middle-end/56924] Folding of checks into a range check should check upper boundary

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-04-12
          Component|c                           |middle-end
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-12 08:44:47 UTC ---
Confirmed.

[Bug middle-end/56924] Folding of checks into a range check should check upper boundary

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---

trunk and FSF 4.9.0 currently generates on ARM. 

        and     r0, r0, #224
        cmp     r0, #224
        bxne    lr
        b       bar


which looks way better than what 4.8 generates.

I'm not sure what fixed this but this certainly looks much better already.

[Bug middle-end/56924] Folding of checks into a range check should check upper boundary

[josh.m.conner at gmail dot com]

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

--- Comment #3 from Joshua Conner <josh.m.conner at gmail dot com> ---
It appears that gcc has a different approach now, which has its own advantages
and disadvantages.  Specifically, when I compile this same example I'm now
seeing an initial tree of:

  if ((SAVE_EXPR <BIT_FIELD_REF <input, 8, 0> & 240>) == 224 || (SAVE_EXPR
<BIT_FIELD_REF <input, 8, 0> & 240>) == 240)
    {
      bar ();
    }

Which indeed generates much better assembly code (for ARM):

        and     r0, r0, #224
        cmp     r0, #224
        beq     .L4

But with a slight modification of the original code to:

  if ((input.val == 0xd) || (input.val == 0xe) || (input.val == 0xf))
    bar();

The tree looks like:

  if (((SAVE_EXPR <BIT_FIELD_REF <input, 8, 0> & 240>) == 208 || (SAVE_EXPR
<BIT_FIELD_REF <input, 8, 0> & 240>) == 224) || (BIT_FIELD_REF <input, 8, 0> &
240) == 240)

And the generated assembly is:

        uxtb    r0, r0
        and     r3, r0, #240
        and     r0, r0, #208
        cmp     r0, #208
        cmpne   r3, #224
        beq     .L4

Which could be much better as:

        ubfx    r0, r0, #4, #4
        cmp     r0, #12
        bhi     .L4

[Bug middle-end/56924] Folding of checks into a range check should check upper boundary

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Mine, bitfield related.