On 02/24/2017 12:07 AM, Alan Modra wrote:
I'm going to wait for Vlad's opinion. I've written a couple of
replies and erased them, since I figure whatever I have to say doesn't
carry much weight.
I would prefer not to touch simplify_subreg_operand, especially a
code related to subreg of mem
I'm going to wait for Vlad's opinion. I've written a couple of
replies and erased them, since I figure whatever I have to say doesn't
carry much weight.
--
Alan Modra
Australia Development Lab, IBM
Alan Modra writes:
> On Thu, Feb 23, 2017 at 11:41:09AM +1030, Alan Modra wrote:
>> lo_sum is indeed not valid for mem:SD. simplify_operand_subreg is
>> where the subreg disappears.
>
> Richard, doesn't the following say that lra is expecting to reload
> exactly the lo_sum address you seem to thi
On Thu, Feb 23, 2017 at 11:41:09AM +1030, Alan Modra wrote:
> lo_sum is indeed not valid for mem:SD. simplify_operand_subreg is
> where the subreg disappears.
Richard, doesn't the following say that lra is expecting to reload
exactly the lo_sum address you seem to think it should not handle in
pr
On Wed, Feb 22, 2017 at 11:01:15PM +, Richard Sandiford wrote:
> Alan Modra 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 with
Alan Modra 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
>
