On Wed, 2008-04-09 at 10:41 -0400, Kenneth Zadeck wrote:
Paolo Bonzini wrote:
Bernd Schmidt wrote:
h8300 and s390, both for paradoxical subregs. subreg of match_operand
is more widespread.
Paolo
does this mean that this is used after reload?
Note that if an md file has
(subreg:DI (match_operand:SI ...))
and you call extract_operands, you will never get a subreg operand. The
subreg is in the insn pattern, not the operand, which is an important
distinction.
You will only see the subreg if you scan RTL insns looking for them,
e.g. by using for_each_rtl.
Usually, when a subreg appears in an insn pattern, it means that we
don't care if the value is sign or zero or otherwise extended. For
instance, in the s390.md file, I see
[(set (reg CC_REGNUM)
(compare (ashiftrt:DI (ashift:DI (subreg:DI (match_operand:SI 0
"register_operand" "d") 0)
(const_int 32)) (const_int 32))
(match_operand:DI 1 "const0_operand" "")))
We are left-shifting a 32-bit value by 32-bits, and then right shifting
it to get it sign-extended. Since we are losing all upper 32-bits of
the value anyways, it makes no difference what kind of extension we
have. Also, since the ashift:DI operator requires a 64-bit input value,
we must extend the SImode input value to DImode somehow to avoid a mode
mismatch. A subreg is an easy and convenient way to do this.
Actually, in this case, the pattern can probably be rewritten to use
sign_extend. Not clear why it wasn't written that way in the first
place.
Just taking a quick look at the h8300 port, it seems to be a similar
issue. Most of the subregs are either inside a left-shift, or outside a
right shift, and are just adding/removing don't-care bits to avoid mode
mismatches. We may be able to rewrite them using sign/zero extend for
the paradoxical case, and truncate for the non-paradoxical case.
Jim
FYI I'm on site for a customer Tue-Thu, so those tend to be busy days
for me. They are even busier now that the US hockey playoffs have
started.