[PATCH] Improve btc (PR target/57819)

[Jakub Jelinek <jakub at redhat dot com>]

Hi!

Kai has reported his type demotion patches lead to a regression, which can
be seen also without his patches by doing the type demotion by hand.
test1 is optimized using *jcc_bt<mode>_mask instruction (combiner detects
this), but test2 isn't.  In that case combiner first merges the and with
shift into *<shift_insn><mode>3_mask insn, and *jcc_bt<mode>_mask won't
match, because we end up with
(zero_extend:SI (subreg:QI (and:SI <something> (const_int 63)) 0))
and we don't simplify that.

So, my first approach was trying to simplify that, because nonzero_bits
on the subreg operand say that no bits outside of QImode may be non-zero,
both the zero_extend and subreg can be dropped.  That is the simplify-rtx.c
change.  Then I've figured out that combine.c doesn't actually attempt to
simplify this anyway, so that is the combine.c change.  And lastly an i386
pattern was needed anyway.  I've also attempted to simplify:
(zero_extend:SI (subreg:QI (and:DI <something> (const_int 63)) 0))
into
(subreg:SI (and:DI <something> (const_int 63)) 0) (very small change in
simplify-rtx.c, just drop the requirement that zero_extend mode is as wide
or wider than SUBREG_REG's mode, and when it is <= use gen_lowpart_no_emit
instead of just returning the SUBREG_REG, but that unfortunately regressed
the test1 case, we'd need some further i386.md tweaks.
While in theory this folding looks like a useful simplification, because
of this I'm wondering if other backends don't rely on those actually not
being simplified.

So, I've as an alternative implemented also an i386.md only fix.

Thus, do we want the first patch, or first patch + also the
above described further simplify-rtx.c change + some further i386.md tweaks,
or just the second patch instead?

Both have been bootstrapped/regtested on x86_64-linux and i686-linux.

	Jakub

Attachment: X964
Description: Text document

Attachment: X964b
Description: Text document