From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: hjl.tools@gmail.com (H.J. Lu)
Cc: gcc-patches@gcc.gnu.org, bernds@codesourcery.com
Subject: Re: PATCH [11/n]: Prepare x32: PR rtl-optimization/48155: Reload doesn't handle subreg properly
Date: Mon, 27 Jun 2011 17:06:00 -0000 [thread overview]
Message-ID: <201106271703.p5RH3A2Q015752@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <BANLkTikBhH3hSCirHvzdzNQGFv9bhMVQog@mail.gmail.com> from "H.J. Lu" at Jun 27, 2011 09:03:56 AM
H.J. Lu wrote:
> On Mon, Jun 27, 2011 at 7:52 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> > H.J. Lu wrote:
> >
> >> Given input:
> >>
> >> (plus:SI (subreg:SI (plus:DI (reg/f:DI 7 sp)
> >> =A0 =A0 =A0 =A0 =A0 =A0 (const_int 16 [0x10])) 0)
> >> =A0 =A0 (const_int -1 [0xffffffffffffffff]))
> >
> > Once again, this seems weird as legitimate address ... =A0If this really
> > can occur validly, there'll probably need to be an insn+splitter and/or
> > a secondard reload provided by the back-end to handle it.
>
> This is the valid memory address for any instructions which
> take a memory operand under x32. How will insn+splitter and/or
> a secondard reload help x32 here? Do I implement such a thing for
> all instructions which take a memory operand?
Well, if this *is* already accepted as valid, then I don't understand
why it is getting reloaded in the first place.
> > With your change below, it seems you're just falling through to
> > the generic gen_rtx_SET case, right? =A0 How does this help?
> >
>
> I added ix86_simplify_base_disp to i386.c to handle such cases.
I see. It appears that this routine is used within ix86_decompose_address,
which means that:
- addresses containing constructs as above will be accepted as valid
- the simplification will *not* be done in place in the RTL stream,
but on the fly every time the address is looked at
This explains why just emitting a plain SET is accepted. But if this
is the case, then the PLUS case in gen_reload should also have worked,
since the first thing it tries is just a plain SET as well:
[snip]
The simplest approach is to try to generate such an insn and see if it
is recognized and matches its constraints. If so, it can be used.
[snip]
insn = emit_insn_if_valid_for_reload (gen_rtx_SET (VOIDmode, out, in));
if (insn)
return insn;
Can you check in your test case why this isn't accepted here?
In general, I'm wondering if it really a good idea to accept
complex non-simplified expressions like the above as valid addresses,
instead of simplifying them directly where they are generated, and
then just accepting the simplified versions. That simplification
could occur e.g. in a secondary reload for PLUS (in those cases
where we actually require a reload), or in a legitimize_reload_address
handler (in those cases where the address can remain in place).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2011-06-27 17:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-25 19:21 H.J. Lu
2011-06-27 15:04 ` Ulrich Weigand
2011-06-27 16:16 ` H.J. Lu
2011-06-27 17:06 ` Ulrich Weigand [this message]
2011-06-28 14:24 ` H.J. Lu
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=201106271703.p5RH3A2Q015752@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=bernds@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.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).