On 10/16/23 21:07, Jeff Law wrote:
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit
registers,
meaning incoming SI function args need not be explicitly sign extended
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU
On 10/11/23 19:37, Hans-Peter Nilsson wrote:
```
foo2:
sext.w a6,a1 <-- this goes away
beq a1,zero,.L4
li a5,0
li a0,0
.L3:
addwa4,a2,a5
addwa5,a3,a5
addwa0,a4,a0
bltua5,a6,.L3
> From: Vineet Gupta
> Date: Thu, 28 Sep 2023 14:43:41 -0700
Please forgive my daftness, but...
> ```
> foo2:
> sext.w a6,a1 <-- this goes away
> beq a1,zero,.L4
> li a5,0
> li a0,0
> .L3:
> addwa4,a2,a5
> addwa5,a3,a5
>
On 10/5/23 07:33, Robin Dapp wrote:
So I think Kenner's code is trying to prevent having a value in a
SUBREG that is inconsistent with the SUBREG_PROMOTED* flag bits. But
I think it's been unnecessary since Matz's rewrite in 2009.
I couldn't really tell what the rewrite does entirely so I
On 10/5/23 08:56, Richard Kenner wrote:
At that particular time I think Kenner was mostly focused on the alpha
and ppc ports, but I think he was also still poking around with romp and
a29k. I think romp is an unlikely target for this because it didn't
promote modes and it wasn't even
> At that particular time I think Kenner was mostly focused on the alpha
> and ppc ports, but I think he was also still poking around with romp and
> a29k. I think romp is an unlikely target for this because it didn't
> promote modes and it wasn't even building for several months
>
> So I think Kenner's code is trying to prevent having a value in a
> SUBREG that is inconsistent with the SUBREG_PROMOTED* flag bits. But
> I think it's been unnecessary since Matz's rewrite in 2009.
I couldn't really tell what the rewrite does entirely so I tried creating
a case where we would
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU
On 10/4/23 12:14, Vineet Gupta wrote:
On 10/4/23 10:59, Jeff Law wrote:
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit
registers,
meaning incoming SI function args
On 10/4/23 10:59, Jeff Law wrote:
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit
registers,
meaning incoming SI function args need not be explicitly sign extended
(so
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU
On 9/29/23 05:14, Jeff Law wrote:
On 9/28/23 21:49, Vineet Gupta wrote:
On 9/28/23 20:17, Jeff Law wrote:
I can bootstrap & regression test alpha using QEMU user mode
emulation. So we might be able to trigger something that way. It'll
take some time, but might prove fruitful.
That
On 9/29/23 04:40, Roger Sayle wrote:
I agree that this looks dubious. Normally, if the middle-end/optimizers
wish to reuse a SUBREG in a context where the flags are not valid, it
should create a new one with the desired flags, rather than "mutate"
an existing (and possibly shared) RTX.
On 9/28/23 21:49, Vineet Gupta wrote:
On 9/28/23 20:17, Jeff Law wrote:
I can bootstrap & regression test alpha using QEMU user mode
emulation. So we might be able to trigger something that way. It'll
take some time, but might prove fruitful.
That would be awesome. It's not like this
I agree that this looks dubious. Normally, if the middle-end/optimizers
wish to reuse a SUBREG in a context where the flags are not valid, it
should create a new one with the desired flags, rather than "mutate"
an existing (and possibly shared) RTX.
I wonder if creating a new SUBREG here also
On 9/28/23 20:17, Jeff Law wrote:
I can bootstrap & regression test alpha using QEMU user mode
emulation. So we might be able to trigger something that way. It'll
take some time, but might prove fruitful.
That would be awesome. It's not like this this is burning or anything
and one of the
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU
19 matches
Mail list logo
