does the instruction combiner regards (foo & 0xff) as a special case?

does the instruction combiner regards (foo & 0xff) as a special case?

[ibanez]

Does the instruction combiner regards (foo & 0xff) as a special case?

I have two patterns which I expect to match all the

if(foo & $(constant)) patterns. They are

  [(set (reg:CC_Z CC_REGNUM)
        (compare:CC_Z
              (and:SI (match_operand:SI 0 "register_operand" "")
                    (match_operand:SI 1 "" ""))
              (const_int 0)))]

   [(set (reg:CC_Z CC_REGNUM)
      (compare:CC_Z (zero_extract:SI
                    (match_operand:SI 0 "register_operand" "")
                    (const_int 1)
                    (match_operand:SI 1 "" ""))
                   (const_int 0)))]

But I found they fails to match

if(foo & 0xff) and if(foo & 0xffff)

Did I forget something ?

Thank you for your reading.

Re: does the instruction combiner regards (foo & 0xff) as a special case?

[Ian Lance Taylor]

ibanez@sunplus.com writes:

> Does the instruction combiner regards (foo & 0xff) as a special case?
> 
> I have two patterns which I expect to match all the
> 
> if(foo & $(constant)) patterns. They are
> 
>   [(set (reg:CC_Z CC_REGNUM)
>         (compare:CC_Z
>               (and:SI (match_operand:SI 0 "register_operand" "")
>                     (match_operand:SI 1 "" ""))
>               (const_int 0)))]
> 
>    [(set (reg:CC_Z CC_REGNUM)
>       (compare:CC_Z (zero_extract:SI
>                     (match_operand:SI 0 "register_operand" "")
>                     (const_int 1)
>                     (match_operand:SI 1 "" ""))
>                    (const_int 0)))]
> 
> But I found they fails to match
> 
> if(foo & 0xff) and if(foo & 0xffff)

Look at the debugging dump before the combine pass to see what you
need to match.

Ian

Re: does the instruction combiner regards (foo & 0xff) as a special case?

[James E Wilson]

ibanez@sunplus.com wrote:
> I guess the combiner generates something like
> a trucation pattern when special constant are detected.
> The combiner also takse a similiar action in pattern

See the section of the documentation that talks about instruction 
canonicalization.
     http://gcc.gnu.org/onlinedocs/gccint/Insn-Canonicalizations.html
See in particular the last bullet.

Also, as Joern mentioned, you should try stepping through try_combine to 
see what is really happening.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: does the instruction combiner regards (foo & 0xff) as a special case?

[ibanez]

You are cool, now I found a

(set (reg:CC_Z 33 cc)
    (compare:CC_Z (zero_extend:SI (subreg:QI (reg/v:SI 166 [ a ]) 0))
        (const_int 0 [0x0])))

It's what I'm looking for.

Thank you so much.

Re: does the instruction combiner regards (foo & 0xff) as a special case?

[Joern RENNECKE]

>> But I found they fails to match
>> 
>> if(foo & 0xff) and if(foo & 0xffff)

These get simplified to foo.

> Look at the debugging dump before the combine pass to see what you
> need to match.

It doesn't work that way.  What you get from there are only the insn numbers.

Then you run cc1 (or whatever languiage-specific compiler you use) under
gdb control, with a breakpoint on the point in try_combine - in this case,
before the first recog_for_combine call - with a condition to match the
insn numbers.  E.g. for breakpoint 5, to match any combination that ends
in insn 42,
you say:

cond 5 i3->u.fld[0].rt_int == 42

to match a combination of insns 40, 41 and 42 (and only in exactly that
order):

cond 5 
i3->u.fld[0].rt_int == 42 && i2->u.fld[0].rt_int == 41 && i1 && i1->u.fld[0].rt_int == 40

or for an older codebase:

i3->fld[0].rtint == 42 && i2->fld[0].rtint == 41 && i1 && i1->fld[0].rtint == 40
 

Re: does the instruction combiner regards (foo & 0xff) as a special case?

[ibanez]

sorry to Ian for replying to the wrong address :)

The result after instruction combination is in *.20.combine
but the rtl pattern *.19.life in

 1.) if(foo & 0x1ff)

 2.) if(foo & 0xff)

are almost the same
I mean the debugging dump only shows the "input" and "output" of
the combination.
But what I wanna know is why the "output"
of case (2) acts against my expection,
and the debugging dump tells nothing about that.
Because things also happens in

  3.) if(foo & 0xffff)

I guess the combiner generates something like
a trucation pattern when special constant are detected.
The combiner also takse a similiar action in pattern

  4.) if(foo & 0x1)

which generates a

    [(set (reg:CC_Z CC_REGNUM)
       (compare:CC_Z (zero_extract:SI
                     (match_operand:SI 0 "register_operand" "")
                     (const_int 1)
                     (match_operand:SI 1 "" ""))
                    (const_int 0)))]
instead of the normal

    [(set (reg:CC_Z CC_REGNUM)
         (compare:CC_Z
               (and:SI (match_operand:SI 0 "register_operand" "")
                     (match_operand:SI 1 "" ""))
               (const_int 0)))]



>ibanez@sunplus.com writes:

>> I have read the debugging dump before I post my question.
>> But the debugging dump is patterns which have
>> successfully matched instead of patterns which
>> combiner tries to match.
>> In other words, the debugging dump does not tell me why
>> combiner use different scheme when the magic
>> numbers 0xff/0xffff are used.
>> Am I wrong?

>Please reply to the mailing list and not just to me.  Thanks.

>The debugging dump from before the combine pass shows the instructions
>which the combine pass sees.  The debugging dump from the combine pass
>shows the instructions after they have been combined.

>The combine pass does put instructions together by substituting the
>source of a set of a pseudo-register for a use of the
>pseudo-register.  So you have to take that into account.  But other
>than that, what you see in the dump before combine is what combine
>will see.

>Ian