On Tue, Jul 5, 2011 at 7:42 AM, Ulrich Weigand <uweig...@de.ibm.com> wrote: > 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.
Here is the problem. For x32, Pmode is the "address_mode". But TARGET_MEM_REF only works on ptr_mode, not Pmode unless Pmode is the same as ptr_mode. > 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. I will give it try. > 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 ... I was told that TARGET_MEM_REF needs ptr_mode. Thanks. -- H.J.
