https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71779
--- Comment #10 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to James Greenhalgh from comment #2)
>
> So I have two questions.
>
> First, where did the DImode paradoxical subreg come from in the first place,
> and why wasn't it a zero-extend?
>
> Second, why did reload decide it was safe to choose a memory location for a
> paradoxical subreg and widen the size of the memory access?
>
the memory access is to a spill slot, but lra is apparently confused by
the paradoxical subreg and does only save 32 bits there while it expects
to read back 64 bits (the widenend &isl_obj_map_vtable):
@@ -4256,29 +4256,28 @@
add w20, w25, :lo12:isl_obj_set_vtable
adrp x28, isl_obj_map_vtable
uxtw x20, w20
- add w0, w28, :lo12:isl_obj_map_vtable
+ add w28, w28, :lo12:isl_obj_map_vtable
mov x21, 0
- str w0, [x29, 112]
- uxtw x0, w0
- str x0, [x29, 96]
+ uxtw x0, w28
+ str x0, [x29, 104]
.p2align 2
...
.L903:
ldr w0, [x19]
- ldr x20, [x29, 112]
- stp w4, w3, [x29, 104]
+ ldr x20, [x29, 104]
+ str w4, [x29, 112]
+ str w3, [x29, 124]
orr x1, x20, x21, lsl 32
bl to_union
- = without patch
+ = with patch
so it looks as if the stack slot x29+112 was only half filled
then read back with stack content
and with the patch from comment#9 it uses less stack slots,
and does uxtw before saving the value to x29+104
So could someone try to boot-strap and reg-test my patch on an aarch64 please?
