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
(so do SI return values as most ALU insns implicitly sign-extend too.)
[...]
---
gcc/expr.cc | 7 -------
gcc/testsuite/gcc.target/riscv/pr111466.c | 15 +++++++++++++++
2 files changed, 15 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/pr111466.c
I created a ChangeLog and pushed this after a final
bootstrap/comparison run on x86_64.
Awesome.
As I've noted before, this has been running across the various targets
in my tester for quite a while with no issues. Additionally Robin and
myself have dug into various paths through expr_expr_real_2 and we're
reasonably confident this is safe (about as much as we can be given
the lack of information about the original patch).
My strong suspicion is that Michael M. made this code obsolete when he
last revamped the gimple/ssa->RTL expansion path.
Thanks for your patience Vineet. It's been a long road.
All the thanks to you for verifying this across targets and deep analysis.
There was a little snafu on my part in the test for which I'll post a fixup.
Jivan is diving into Joern's work. It shows significant promise,
though we are seeing some very weird behavior on perlbench.
That's great to hear. I was away from sign extension work much of last
week. Back on it now. The prev example I was chasing
(gcc.c-torture/compile/20040401-1.c) turned out to be a dead end as it
has explicit casts and such so not an ideal case. I'm sifting through
the logs and looking for better tests, there's a ton of them so I'm sure
there's bunch more we can do at expand time to eliminate extensions
early which as you mentioned is better in general, to have to "undo"
less in later passes.
Thx,
-Vineet
