* Re: does the instruction combiner regards (foo & 0xff) as a special case?
@ 2005-08-01 8:42 ibanez
2005-08-02 17:45 ` James E Wilson
0 siblings, 1 reply; 6+ messages in thread
From: ibanez @ 2005-08-01 8:42 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: does the instruction combiner regards (foo & 0xff) as a special case?
2005-08-01 8:42 does the instruction combiner regards (foo & 0xff) as a special case? ibanez
@ 2005-08-02 17:45 ` James E Wilson
0 siblings, 0 replies; 6+ messages in thread
From: James E Wilson @ 2005-08-02 17:45 UTC (permalink / raw)
To: ibanez; +Cc: gcc
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: does the instruction combiner regards (foo & 0xff) as a special case?
@ 2005-08-02 7:50 ibanez
0 siblings, 0 replies; 6+ messages in thread
From: ibanez @ 2005-08-02 7:50 UTC (permalink / raw)
To: Joern RENNECKE; +Cc: gcc, Ian, ibanez, Lance, Taylor
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: does the instruction combiner regards (foo & 0xff) as a special case?
@ 2005-08-01 16:12 Joern RENNECKE
0 siblings, 0 replies; 6+ messages in thread
From: Joern RENNECKE @ 2005-08-01 16:12 UTC (permalink / raw)
To: Ian, Lance, Taylor, ibanez; +Cc: gcc
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: does the instruction combiner regards (foo & 0xff) as a special case?
2005-08-01 2:48 ibanez
@ 2005-08-01 2:57 ` Ian Lance Taylor
0 siblings, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 2005-08-01 2:57 UTC (permalink / raw)
To: ibanez; +Cc: gcc
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* does the instruction combiner regards (foo & 0xff) as a special case?
@ 2005-08-01 2:48 ibanez
2005-08-01 2:57 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: ibanez @ 2005-08-01 2:48 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-08-02 17:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-08-01 8:42 does the instruction combiner regards (foo & 0xff) as a special case? ibanez
2005-08-02 17:45 ` James E Wilson
-- strict thread matches above, loose matches on Subject: below --
2005-08-02 7:50 ibanez
2005-08-01 16:12 Joern RENNECKE
2005-08-01 2:48 ibanez
2005-08-01 2:57 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).