Re: combine/dce patch for PR36003, PR42575

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Tue, 22 Jun 2010, Bernd Schmidt wrote:
> PR36003 is a problem where enabling pass_fast_rtl_byte_dce causes
> crashes in a cris compiler when the host is 64 bit.  combine produces an
> insn of the form
>
> (set (cc0)
>         (zero_extract:DI (subreg:SI (reg/v:DI 38 [ high ]) 0)
>             (const_int 1 [0x1])
>             (const_int 0 [0x0]))) 16 {*btst} (nil))
>
> The cris backend accepts this

Look again!

> since it does not specify a mode for the
> zero_extract, but IMO this is invalid, as the documentation states
>
>      If LOC is in a register, the mode to use is specified by the
>      operand of the `insv' or `extv' pattern (*note Standard Names::)
>      and is usually a full-word integer mode, which is the default if
>      none is specified.

The RTL may be invalid, but none was specified in the port, just
like the doc says.  So, I guess rtl.texi should change too?

Anyway.  That changed about a year ago: Bonzini's condition-code
rewrite (r147425).  It is now has a mode (and is wrapped in a
modeless compare).

> [...]
>      The mode M is the same as the mode that would be used for LOC if
>      it were a register.
>
> which seems to imply that the zero_extract and its first operand should
> both have word_mode.  The DImode zero_extract of a SImode value seems to
> confuse pass_fsat_rtl_byte_dce.

I find that reference in rtl.texi so IIUC is regarding valid
RTX, not what a port has to assert or refuse.  In this respect,
the port was consistent with the compare insns; there's no mode
on the compare, just the operands of the compare.  I can't find
whatever documentation specified this, maybe I found nothing at
the time was just using the m68k-port as effective
documentation, which had the same modeless zero_extract
assigning to cc0 *at the time*.  Whatever, all this *has*
changed.  Water under the bridges...

brgds, H-P