On Wed, Feb 22, 2017 at 11:01:15PM +0000, Richard Sandiford wrote:
> Alan Modra <amo...@gmail.com> writes:
> > This patch allows lra to reload a lo_sum address. Given a mem with a
> > lo_sum address as used by ppc32, decompose_mem_address returns an
> > address_info with *base the lo_sum and *base_term the reg within the
> > lo_sum. When a lo_sum address isn't valid, we want to first try
> > reloading the entire lo_sum to a new reg. I first fixed that, then
> > hit another ICE, this time in gen_int_mode. gen_int_mode was being
> > called with the mode of the memory access, not the mode of the
> > address.
>
> It seems odd that we have a lo_sum address for a mode that doesn't
> accept lo_sums. I don't think that was one of the "three" cases
> anticapted in:
>
> /* There are three cases where the shape of *AD.INNER may now be invalid:
>
> 1) the original address was valid, but either elimination or
> equiv_address_substitution was applied and that made
> the address invalid.
>
> 2) the address is an invalid symbolic address created by
> force_const_to_mem.
>
> 3) the address is a frame address with an invalid offset.
>
> 4) the address is a frame address with an invalid base.
>
> All these cases involve a non-autoinc address, so there is no
> point revalidating other types. */
>
> It sounds from the PR comments like a valid lo_sum in a mem:SI
> somehow becomes an invalid lo_sum in a mem:SD through equivalence,
> is that right?
Yes, that it correct.
> If so, was there a (subreg:SD (reg:SI ...)) in the
> pre-RA insn that got "simplifed" to a (mem:SD (lo_sum ...)) during LRA?
Yes. The insn in question out of ira is this one:
(insn 11 7 10 2 (set (reg:SD 33 1)
(subreg:SD (reg:SI 155 [ i.0_1 ]) 0))
"/home/alan/src/gcc.git/gcc/testsuite/c-c++-common/dfp/pr35620.c":20 489
{movsd_hardfloat}
(nil))
(reg:SI 155) has the equivalence with
(mem/j/c:SI (lo_sum:SI (reg/f:SI 160) (symbol_ref:SI ("u"))))
At the time we fail valid_address_p, lra is looking at
(insn 11 17 10 2 (set (reg:SD 33 1)
(mem/j/c:SD (lo_sum:SI (reg/f:SI 160)
(symbol_ref:SI ("u") [flags 0x84] <var_decl 0x7ffff7ff5510 u>))
[2 u.b+0 S4 A32]))
"/home/alan/src/gcc.git/gcc/testsuite/c-c++-common/dfp/pr35620.c":20 489
{movsd_hardfloat}
> IMO the bug's in that step if so and if lo_sum isn't valid for mem:SD.
lo_sum is indeed not valid for mem:SD. simplify_operand_subreg is
where the subreg disappears.
[snip]
> I don't think the code was ever intended to handle anything
> that complicated. The address has to be "basically" valid,
> except in the cases above.
I'm seriously regretting my foray into ira.c, attempting to modernize
just a small part of the code to use the DF infrastructure..
--
Alan Modra
Australia Development Lab, IBM
