PATCH: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

[Richard Guenther]

On Sun, Feb 13, 2011 at 2:41 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Feb 13, 2011 at 1:42 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>>>> rtx
>>>> addr_for_mem_ref (struct mem_address *addr, addr_space_t as,
>>>>                  bool really_expand)
>>>> {
>>>>  enum machine_mode address_mode = targetm.addr_space.address_mode (as);
>>>>
>>>> address_mode will be Pmode - that would be already wrong.  We need to
>>>> use ptr_mode here and at the end of the function convert the
>>>> generated address to Pmode appropriately.  Can you verify that theory?
>>>>
>>>
>>> This patch works for me.  However, if I add
>>>
>>> diff --git a/gcc/tree-ssa-address.c b/gcc/tree-ssa-address.c
>>> index 7b7e169..d9d906e 100644
>>> --- a/gcc/tree-ssa-address.c
>>> +++ b/gcc/tree-ssa-address.c
>>> @@ -242,6 +242,9 @@ addr_for_mem_ref (struct mem_address *addr, addr_space_t as,
>>>       if (off)
>>>   *templ->off_p = off;
>>>
>>> +      if (targetm.addr_space.address_mode (as) != ptr_mode)
>>> +  templ->ref = convert_to_mode (targetm.addr_space.address_mode (as),
>>> +                 templ->ref, 1);
>>>       return templ->ref;
>>>     }
>>>
>>> to convert MEM_REF from ptr_mode to Pmode, I get
>>>
>>> /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
>>> -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32
>>> -O2 -g -fPIC    x.i
>>> x.i: In function \u2018foo\u2019:
>>> x.i:21:1: error: insn outside basic block
>>> (insn 88 0 113 (parallel [
>>>            (set (reg:SI 143)
>>>                (ashift:SI (reg:SI 60)
>>>                    (const_int 3 [0x3])))
>>>            (clobber (reg:CC 17 flags))
>>>        ]) -1
>>>     (nil))
>>> x.i:21:1: internal compiler error: in rtl_verify_flow_info, at cfgrtl.c:2218
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See <http://gcc.gnu.org/bugs.html> for instructions.
>>> make: *** [x.s] Error 1
>>>
>>> Do I really need to convert MEM_REF from ptr_mode to Pmode?
>>
>> Only if you do not plan to support 32bit addresses in the backend.
>
> What do you mean by that? x32 is 32bit address.

I mean if the backend MEMs only accept Pmode (64bit), not
ptr_mode (32bit).

Richard.

>> The above is probably
>> because the caller context from where that function is called isn't
>> prepared to have
>> instructions emitted (maybe it's called from the cost analysis pieces as well?)
>>
>
> This could be true.
>
> --
> H.J.
>