https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #25 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I don't see the distinction here. Ia64 has instructions that operate on
> 32-bit values too, like cmp4.
The distinction is precisely what WORD_REGISTER_OPERATIONS conveys. On SPARC
and MIPS for example, for a 32-bit operation in 64-bit mode, the entire 64-bit
register is modified and the upper bits contain well defined bits.
> On sparc, given this testcase
> int
> sub (int i, int j, int k)
> {
> return i + j + k;
> }
> the compiler generates
> sub:
> add %o0, %o1, %o0
> add %o0, %o2, %o0
> jmp %o7+8
> sra %o0, 0, %o0
> Note that the add instruction operates on the entire 64-bit register, and
> after the first add, we no longer have a valid 32-bit value, because there
> might have been an overflow. This is why we need the sra at the end to
> sign-extend the return value, because we know that the upper 32-bits are
> don't care bits.
No, the upper bits are well defined by the SPARC-V9 architecture.
> If you take a paradoxical subreg of a SImode reg after an add instruction,
> you can't make any assumptions about the upper 32-bits of the value in the
> register. Exactly the same as ia64.
No, you know what the bits are on SPARC and MIPS for example if you know the
contents of the entire 64-bit register before the addition.
> I do see that the fact that sparc has 32-bit shift instructions defined
> means the testcase that fails on ia64 will not fail on sparc. But if we
> rely on that for the WORD_REGISTER_OPERATIONS definition, then it gets even
> messier than it already is.
I agree that we may need to do something for operations that don't have a clear
meaning when "extended" to the full work though.
Let me give it some thought...
