Jeff Law <jeffreya...@gmail.com> writes:
> On 7/4/25 10:21 AM, Richard Sandiford wrote:
>> ext-dce had:
>>
>> if (SUBREG_P (dst) && SUBREG_BYTE (dst).is_constant ())
>> {
>> bit = subreg_lsb (dst).to_constant ();
>> if (bit >= HOST_BITS_PER_WIDE_INT)
>> bit = HOST_BITS_PER_WIDE_INT - 1;
>> dst = SUBREG_REG (dst);
>>
>> But a constant SUBREG_BYTE doesn't guarantee a constant subreg_lsb.
>> If the SUBREG_REG is a pair of N-bit registers on a big-endian target,
>> the most significant end has a SUBREG_BYTE of 0 but a subreg_lsb of N.
>> This N would then be non-constant for variable-length registers.
>>
>> The patch fixes gcc.dg/torture/pr120276.c and other failures on
>> aarch64_be-elf.
>>
>> Tested on aarch64-linux-gnu & aarch64_be-elf. OK to install?
>>
>> Richard
>>
>>
>> gcc/
>> * ext-dce.cc (ext_dce_process_uses): Apply is_constant directly
>> to the subreg_lsb.
> OK, of course.
Thanks.
> Makes me wonder if I should resurrect my aarch64_be RFS. I changed how
> those systems worked in the system a few years back to make it work
> better with container based testing rather than direct chroots. I never
> converted aarch64_be to that setup. It shouldn't be hard if you think
> it's valuable.
I'm not sure TBH. The only reason I started looking at aarch64_be
recently was to test a patch for Konstantinos. And it turns out that
the "before" results are really, really poor. I think that suggests
that no-one on the AArch64 side is testing big-endian regularly.
(And LLVM have got away without ever implementing big-endian arm_sve.h
support.) So there's a danger that you'd spend a lot of your time
triaging AArch64-specific bugs. There again, like you say...
> I can't think of another system where we'd these kinds of issues.
...it probably does have some "unique" features. :)
I later came across another instance of the subreg_lsb thing, which was
causing other ICEs. I went ahead and installed this as obvious, given
the approval for the earlier one.
Tested on aarch64-linux-gnu and aarch64_be-elf.
Richard
This patch fixes another instance of the problem described in the
cover note for g:bf3037e923e9f91d93ab64bdf73a37f64f659fb9.
gcc/
* ext-dce.cc (ext_dce_process_uses): Apply is_constant directly
to the subreg_lsb.
---
gcc/ext-dce.cc | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc
index e7635fb7a39..67ec92a4287 100644
--- a/gcc/ext-dce.cc
+++ b/gcc/ext-dce.cc
@@ -757,7 +757,7 @@ ext_dce_process_uses (rtx_insn *insn, rtx obj,
and process the inner object. */
if (paradoxical_subreg_p (y))
y = XEXP (y, 0);
- else if (SUBREG_P (y) && SUBREG_BYTE (y).is_constant ())
+ else if (SUBREG_P (y) && subreg_lsb (y).is_constant (&bit))
{
/* If !TRULY_NOOP_TRUNCATION_MODES_P, the mode
change performed by Y would normally need to be a
@@ -774,8 +774,6 @@ ext_dce_process_uses (rtx_insn *insn, rtx obj,
GET_MODE (SUBREG_REG (y))))))
break;
- bit = subreg_lsb (y).to_constant ();
-
/* If this is a wide object (more bits than we can fit
in a HOST_WIDE_INT), then just break from the SET
context. That will cause the iterator to walk down
--
2.43.0
