On Dec 10, 2023, Jeff Law <jeffreya...@gmail.com> wrote:
> On 12/8/23 19:25, Alexandre Oliva wrote:
>> On aarch64 -milp32, and presumably on other such targets, ptr can be
>> in a different mode than ptr_mode in the testcase. Cope with it.
>> Regstrapped on x86_64-linux-gnu, also tested the new test on
>> aarch64-elf. Ok to install?
>>
>> for gcc/ChangeLog
>> PR target/112804
>> * builtins.cc (try_store_by_multiple_pieces): Use ptr's mode
>> for the increment.
>> for gcc/testsuite/ChangeLog
>> PR target/112804
>> * gcc.target/aarch64/inline-mem-set-pr112804.c: New.
> Hmmm. I'd like a little more information here I wouldn't expect those
> modes to differ even for ILP32 on a 64bit target. Are we just
> papering over a problem elsewhere?
Possibly. I've run into Pmode/ptr_mode issues before, so I didn't give
it much thought.
Despite ptr_mode's being SImode, and DEST being a 32-bit pointer,
expand_builtin_memset_args gets from get_memory_rtx a (MEM:BLK (REG:DI))
The expansion of dest to RTL is convoluted. It is first computed in:
(set (reg:DI 102)
(plus:DI (reg/f:DI 95 virtual-stack-vars)
(const_int -264 [0xfffffffffffffef8])))
in DImode because virtual-stack-vars is DImode, then it's
SUBREG-narrowed to SImode in expand_expr_addr_expr_1 because of
new_tmode (== pointer_mode), and that's the address stored in addr and
passed to memory_address in get_memory_rtx.
But then something unexpected happens: memory_address_addr_space extends
it back to DImode because address_mode = targetm.addr_space.address_mode
() = Pmode:
(set (reg:DI 103)
(zero_extend:DI (subreg:SI (reg:DI 102) 0)))
and it's a MEM with (reg:DI 103) as the address that gets passed to
clear_storage_hints, and then try_store_by_multiple_pieces, where the
address is copied from the MEM into ptr, and then, in the update_needed
case I modified in the proposed patch, it gets incremented.
So it looks like my hunch that this was a Pmode/ptr_mode issue was
correct, and I don't see anything particularly fishy in the conversions
above. Do you?
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
