This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: hjl dot tools at gmail dot com (H.J. Lu)
- Cc: richard dot guenther at gmail dot com (Richard Guenther), gcc-patches at gcc dot gnu dot org, Ulrich dot Weigand at de dot ibm dot com (Ulrich Weigand)
- Date: Tue, 5 Jul 2011 16:56:29 +0200 (CEST)
- Subject: Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode
H.J. Lu wrote:
> > 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. =A0If
> > 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.
Can you elaborate? We are talking about the mode returned from
addr_for_mem_ref here. I do now understand how this can be anything
but an address mode:
If you look at the users of addr_for_mem_ref, they all look someting
like this:
op0 = addr_for_mem_ref (&addr, as, true);
op0 = memory_address_addr_space (mode, op0, as);
mem = gen_rtx_MEM (mode, op0);
So the result is used as address argument to create a MEM. This must
certainly be address mode (Pmode) then -- that's basically the definition
of address mode (the mode of the address argument to MEM).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com