Should the `expand` functions in builtin.c generate MEM patterns with ptr_mode addresses (instead of Pmode)
Wed Jul 1 10:19:15 GMT 2020
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
More information about the Gcc