https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-03-18
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #2)
> (This is on a PowerPC 750).
>
> The compiler makes an unaligned store for this, because it knows no better
> than it is just a SImode store:
>
> d_5 = (int) f_4(D);
> _10 = (unsigned int) d_5;
> MEM[(short int *)p_7(D) + 6B] = _10;
>
> and *normal* unaligned stores of SImode are just fine -- they just cause
> an extra access if crossing an 8B boundary. OTOH, floating point load/store
> cause a misalignment interrupt if unaligned.
And note that RTL expansion correctly marks the MEM as having only 16 bits
alignment:
;; MEM[(short int *)p_7(D) + 6B] = _10;
(insn 7 6 8 (parallel [
(set (reg:SI 125)
(fix:SI (reg/v:SF 124 [ f ])))
(clobber (scratch:DI))
]) "t.c":9:7 -1
(nil))
(insn 8 7 0 (set (mem:SI (plus:DI (reg/v/f:DI 123 [ p ])
(const_int 6 [0x6])) [1 MEM[(short int *)p_7(D) + 6B]+0 S4
A16])
(reg:SI 125)) "t.c":9:7 -1
(nil))
so this is clearly a target issue manifesting in combine:
Trying 7 -> 8:
7: {r125:SI=fix(r127:SF);clobber scratch;}
REG_DEAD r127:SF
8: [r126:DI+0x6]=r125:SI
REG_DEAD r126:DI
REG_DEAD r125:SI
Successfully matched this instruction:
(parallel [
(set (mem:SI (plus:DI (reg:DI 126)
(const_int 6 [0x6])) [1 MEM[(short int *)p_7(D) + 6B]+0 S4
A16])
(fix:SI (reg:SF 127)))
(clobber (scratch:DI))
])
allowing combination of insns 7 and 8
the pattern shouldn't have matched with the possibly unaligned store.
