From: Richard Sandiford <rdsandiford@googlemail.com>
To: Alan Modra <amodra@gmail.com>
Cc: gcc-patches@gcc.gnu.org, Vladimir Makarov <vmakarov@redhat.com>
Subject: Re: [PATCH] PR79584, lra ICE in base_to_reg
Date: Fri, 24 Feb 2017 00:35:00 -0000 [thread overview]
Message-ID: <871suoh3jm.fsf@googlemail.com> (raw)
In-Reply-To: <20170223014659.GM14945@bubble.grove.modra.org> (Alan Modra's message of "Thu, 23 Feb 2017 12:16:59 +1030")
Alan Modra <amodra@gmail.com> 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 think it should not handle in
> process_address?
>
> /* We still can reload address and if the address is
> valid, we can remove subreg without reloading its
> inner memory. */
> && valid_address_p (GET_MODE (subst),
> regno_reg_rtx
> [ira_class_hard_regs
> [base_reg_class (GET_MODE (subst),
> MEM_ADDR_SPACE (subst),
> ADDRESS, SCRATCH)][0]],
> MEM_ADDR_SPACE (subst))))
Yeah, I think that's a bit too broad. It was added in:
2016-02-03 Vladimir Makarov <vmakarov@redhat.com>
Alexandre Oliva <aoliva@redhat.com>
PR target/69461
* lra-constraints.c (simplify_operand_subreg): Check additionally
address validity after potential reloading.
(process_address_1): Check insns validity. In case of failure do
nothing.
to allow the subreg to be simplified for the stack mem:
(mem/c:V2DF (plus:DI (reg/f:DI 113 sfp)
(const_int 96 [0x60])) [6 %sfp+96 S16 A128])
Coping with that kind of stack address is no problem. But the patch
seems to allow any other address through as well, even though
process_address_1 still has the old assumption that the address is
"basically" valid. E.g. as well as the assert you were patching,
there's:
/* Any index existed before LRA started, so we can assume that the
presence and shape of the index is valid. */
push_to_sequence (*before);
lra_assert (ad.disp == ad.disp_term);
which could also fire if we allow an address that has the right shape
for one mode to be used with any other mode.
The patch made process_address_1 punt and return false for the MEM
quoted above. I think it'd be dangerous to extend that to all
other types of MEM. Wouldn't that require the target to provide a
load-address pattern for every possible MEM address? E.g. if the
address requires relocation operators, the load-address version might
need a different relocation sequence from the load/store version.
Thanks,
Richard
next prev parent reply other threads:[~2017-02-23 23:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-22 21:22 Alan Modra
2017-02-22 23:14 ` Richard Sandiford
2017-02-23 1:21 ` Alan Modra
2017-02-23 1:49 ` Alan Modra
2017-02-24 0:35 ` Richard Sandiford [this message]
2017-02-24 5:20 ` Alan Modra
2017-02-25 7:42 ` Vladimir Makarov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871suoh3jm.fsf@googlemail.com \
--to=rdsandiford@googlemail.com \
--cc=amodra@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=vmakarov@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).