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
