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

[Jeff Law]

On Wed, 2020-07-01 at 11:19 +0100, Matthew Malcomson wrote:
> 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).
In general, most things should be using Pmode.  However, you have to be careful
when you're dealing with the memory storage vs an address we're actually going to
use in a memory dereference, pointer arithmetic, etc.  This distinction comes up
in trampolines because they have to pull a pointer out of memory, then use it. 
So there's some parts that use ptr_mode and others in Pmode.

Few targets have to deal with this stuff, so it's  a bit fragile and not terribly
well documented.

jeff