On Fri, 16 Sep 2022 16:48:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 9/6/22 05:39, Alexander Monakov via Gcc-patches wrote:
On Mon, 5 Sep 2022, Philipp Tomsich wrote:
+riscv_mode_rep_extended (scalar_int_mode mode, scalar_int_mode mode_rep)
+{
+ /* On 64-bit targets, SImode register values are sign-extended to DImode. */
+ if (TARGET_64BIT && mode == SImode && mode_rep == DImode)
+ return SIGN_EXTEND;
I think this leads to a counter-intuitive requirement that a hand-written
inline asm must sign-extend its output operands that are bound to either
signed or unsigned 32-bit lvalues. Will compiler users be aware of that?
Is this significantly different than on MIPS? Hand-written code there
also has to ensure that the results are properly sign extended and it's
been that way for 20+ years since the introduction of mips64 IIRC.
Though I don't think we had MODE_REP_EXTENDED that long.
IMO the problem isn't so much that asm has this constraint, it's that
it's a new constraint and thus risks breaking code that used to work.
That said...
Haha, MIPS is the only target that currently defines
TARGET_MODE_REP_EXTENDED :-)
Moreover, without adjusting TARGET_TRULY_NOOP_TRUNCATION this should cause
miscompilation when a 64-bit variable is truncated to 32 bits: the pre-existing
hook says that nothing needs to be done to truncate, but the new hook says
that the result of the truncation is properly sign-extended.
The documentation for TARGET_MODE_REP_EXTENDED warns about that:
In order to enforce the representation of mode,
TARGET_TRULY_NOOP_TRUNCATION
should return false when truncating to mode.
This may well need adjusting in Philipp's patch. I'd be surprised if
the MIPS definition wasn't usable nearly verbatim here.
Yes, and we have a few MIPS-isms in the ISA but don't have the same
flavor of TRULY_NOOP_TRUNCATION. It's been pointed out a handful of
times and I'm not sure what the right way to go is here, every time I
try and reason about which is going to produce better code I come up
with a different answer. IIRC last time I looked at this I came to the
conclusion that we're doing the right thing for RISC-V because most of
our instructions implicitly truncate. It's pretty easy to generate bad
code here and I'm pretty sure we could fix some of that by moving to a
more MIPS-like TRULY_MODE_TRUNCATION, but I think we'd end up just
pushing the problems around.
Every time I look at this I also get worried that we've leaked some of
these internal promotion rules into something visible to inline asm, but
when I poke around it seems like things generally work.
jeff
