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)))]
>[EMAIL PROTECTED] 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
