https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #12 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> Could we fix this up in postreload or later?
> (insn 35 18 21 2 (set (reg:SI 0 x0 [125])
> (reg:SI 32 v0 [117])) "pr104049.c":16:33 52 {*movsi_aarch64}
> (nil))
> (insn 21 35 36 2 (set (reg:SI 0 x0 [120])
> (and:SI (reg:SI 0 x0 [125])
> (const_int 65535 [0xffff]))) "pr104049.c":16:33 500 {andsi3}
> (nil))
> (insn 36 21 22 2 (set (reg:SI 1 x1 [126])
> (reg:SI 32 v0 [117])) "pr104049.c":16:33 52 {*movsi_aarch64}
> (nil))
> (insn 22 36 28 2 (set (reg:SI 0 x0 [121])
> (plus:SI (lshiftrt:SI (reg:SI 1 x1 [126])
> (const_int 16 [0x10]))
> (reg:SI 0 x0 [120]))) "pr104049.c":16:33 211 {*add_lsr_si}
> (nil))
>
> transformation into:
> (insn 35 18 21 2 (set (reg:SI 0 x0 [125])
> (reg:SI 32 v0 [117])) "pr104049.c":16:33 52 {*movsi_aarch64}
> (nil))
> (insn 21 35 22 2 (set (reg:SI 0 x1 [120])
> (and:SI (reg:SI 0 x0 [125])
> (const_int 65535 [0xffff]))) "pr104049.c":16:33 500 {andsi3}
> (nil))
> (insn 22 21 28 2 (set (reg:SI 0 x0 [121])
> (plus:SI (lshiftrt:SI (reg:SI 1 x0 [126])
> (const_int 16 [0x10]))
> (reg:SI 0 x1 [120]))) "pr104049.c":16:33 211 {*add_lsr_si}
> (nil))
> ?
Yeah I think so, normally -frename-registers would have done it but it doesn't
find the opportunity in this case because of the zero extend which clobbers x0
before the second extract. So I think purely the instruction scheduling causes
a problem here. So it's probably better to clean it up pre-reload if possible.
