[Bug target/15184] [4.8/4.9/5 Regression] Direct access to byte inside word not working with -march=pentiumpro

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #29 from Jeffrey A. Law <law at redhat dot com> ---
I can certainly understand wanting to handle this in the bswap pass and if you
can make it fly there, that's obviously good.

But I also wonder if we're just being dumb in combine and the x86 backend in
terms of recognizing when a blob of RTL really just represents a bitfield
insertion.

Isn't the first case just:

(define_insn_and_split ""
  [(set (match_operand:SI 0 "register_operand")
        (ior:SI (and:SI (match_operand:SI 1 "register_operand")
                        (match_operand 3 "const_int_operand"))
                (zero_extend:SI (match_operand 2 "register_operand"))))]
  "INTVAL (operands[3]) == ~GET_MODE_MASK (GET_MODE (operands[2]))"
  "#"
  ""
  [(set (match_dup 0) (match_dup 1))
   (set (zero_extract (match_dup 0)
                      (match_dup 4)
                      (const_int 0))
        (match_dup 2))]
"{
  operands[4] = GEN_INT (GET_MODE_BITSIZE (GET_MODE (operands[2])));
}")



The second case is similar, except we have another AND expression rather than
the zero_extend in the pattern because we're inserting into a middle byte.

Cases #3 and #4 appear to be more complex, but that may be a failing in the
combine simplifications and canonicalization.  I haven't looked deeply yet.