Should the `expand` functions in builtin.c generate MEM patterns with ptr_mode addresses (instead of Pmode)

[Matthew Malcomson]

Hello,

I asked on IRC on Monday but since it didn't get any responses and the 
mailing list doesn't require someone paying attention at the moment I 
ask I'm asking here too.


I've seen that  `expand_builtin_init_trampoline` generates a 
`gen_rtx_MEM (BLKmode, ...)` on something returned from `expand_normal`.

On AArch64 with `-mabi=ilp32` the address from `expand_normal` is in 
`ptr_mode` which is SImode.

This means the RTX the backend gets is something like `(mem:BLK (reg:SI 
...))`


Since Pmode is DImode in the AArch64 backend, this is a little awkward 
to deal with.
The current code works with `ptr_mode`, but it calls a function path 
which ICE's on a larger trampoline size.


Many other functions in builtins.c generate MEM patterns with a Pmode 
address by either using `convert_memory_address` (like 
expand_builtin_nonlocal_goto and expand_builtin_atomic_compare_exchange) 
or using `memory_address` through `get_mem_rtx` (like 
expand_builtin_strncpy, expand_movstr, or expand_builtin_memory_copy_args).


Is this generation of such MEM patterns with ptr_mode rather than Pmode 
in expand_builtin_init_trampoline and expand_builtin_init_descriptor 
deliberate, or should we change them?
(Note I guess that passing a different mode to the backends might cause 
ICE's that will need to be fixed on a few different targets -- it would 
on AArch64).


Thanks,
Matthew