PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

[Ulrich Weigand]

Richard Guenther wrote:

> That doesn't look correct without also ensuring we never create a
> TARGET_MEM_REF with a base that is not in the default address-space.
> In fact, with this patch the address-space argument to addr_for_mem_ref
> should go away or we need a hook that provides a non-promoted mode
> for address-spaces.
> 
> Uli?

Common code should basically *never* directly refer to Pmode or ptr_mode;
instead it should always use the per-address-space modes
   targetm.addr_space.address_mode (as)
or
   targetm.addr_space.pointer_mode (as)

The "address_mode" is the mode to handle addresses at the instruction level
(i.e. the mode of the address within a MEM (or TARGET_MEM_REF)).  This
defaults to Pmode for the default address space.

The "pointer_mode" is the mode to handle pointers at source level.  This
defaults to ptr_mode for the default address space.

[ Note that there is one exception: common code today continues to hard-
code Pmode for addresses known to refer to the stack; the stack must lie
in the default address space at this point. ]

So the patch below, changing targetm.addr_space.address_mode (as) to
just "ptr_mode" is definitely wrong and will break multiple address
spaces.  If at this point indeed a pointer mode is required, you should
use targetm.addr_space.pointer_mode (as) instead.

However, this still seems odd to me, as I had understood the address in
a TARGET_MEM_REF needs to be an *address*, i.e. use address_mode.  If
this is not true (has changed?) a lot of other places would need to
change as well ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com