From: Georg-Johann Lay <avr@gjlay.de>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Reload pass ignores constraints. Why?
Date: Wed, 15 Apr 2009 16:55:00 -0000 [thread overview]
Message-ID: <49E62055.1020007@gjlay.de> (raw)
In-Reply-To: <m3ljq2xa8v.fsf@google.com>
Ian Lance Taylor schrieb:
> Georg-Johann Lay <avr@gjlay.de> writes:
>
>>> that--if LEGITIMATE_CONSTANT_P accepts 0xffffff--then you need to ensure
>>> that your movsi insn will handle 0xffffff directly, without using any
>>> pseudo-registers when can_create_pseudo_p returns false.
>> That works, of course. But I must admit that I prefer to express what
>> is going on in terms of algebra, i.e. in terms of RTL instead of
>> acting as if the core could handle the constant and just printng out
>> some asm sequencs. movsi expands constants that cannot be loaded in
>> one machine instruction to a movesi_insn and an arithmetic insn, and
>> movsi_insn therefore allows only constants that are easy to load.
>
> You shouldn't print out some asm sequence, you should make movsi a
> define_expand which emits a sequence of insns which do not require new
> pseudo-registers. See, e.g., mips_move_integer which is called
> (indirectly) by the mov<mode> define_expand in mips.md.
Up to now, I see the following stategies:
i) Expand to a single insn that matched by *movsi_insn:
Bad, because not optimal and the insn output will print several
asm statements en bloc (the movsi expander does not print
anything, of course)
ii) Expand into MOV+LSHIFTRT and deny the resulting const in
*movsi_insn predicate and condition:
Bad, because it crashes reload (as we saw above)
iii) Expand into MOV+LSHIFTRT and allow the resulting const in
*movsi_insn:
CSE et. al. will reconstruct the original constant and
replace MOV+LSHIFTRT with a single SET:
Bad: expanding was in vain and we Goto i)
iv) Expand into MOV+LSHIFTRT and remove the const from
LEGITIMATE_CONSTANT_P:
Bad, because constant will end up in constant pool.
v) Expand into MOV+ADD sequence. Works(?), but
Bad: Code bloat of 100% compared to optimum.
Ok, I could catch it in a peep2...
The difference is that in contrast to lshiftrt the add
can handle the required addition without need of reloads.
vi) Expand into MOV+LSHIFTRT and allow the constand only if
reload_in_progress||reload_completed:
Bad: runs into ICE
I didn't follow this path any further. Looks too hacky.
The movMM expa
>
>> What I do not understand is that a MOV/ADD sequence (which covers
>> large constants) works on RTL level, whereas MOV/SHIFTRT (which is
>> more efficient in some cases) shreds global alloc. Other strategies
>> could be MOV/[AND|IOR|XOR|BSWAP...] which won't work either, though.
>
> I don't know exactly what is going on. But it is most likely just a
> coincidence that it is failing when using SHIFTRT. There is probably
> some way to make it fail in other ways as well.
Would state it like this: If the movMM expander expands the move into
several insns, each insn must be able to handle an alternative (which
reload might select) without needing a reload.
Georg-Johann
next prev parent reply other threads:[~2009-04-15 16:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-14 9:35 Georg-Johann Lay
2009-04-14 14:43 ` Ian Lance Taylor
2009-04-14 18:12 ` Georg-Johann Lay
2009-04-14 20:54 ` Ian Lance Taylor
2009-04-15 12:00 ` Georg-Johann Lay
2009-04-15 14:28 ` Ian Lance Taylor
2009-04-15 16:55 ` Georg-Johann Lay [this message]
2009-04-15 18:31 ` Ian Lance Taylor
2009-04-17 15:34 ` Georg-Johann Lay
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=49E62055.1020007@gjlay.de \
--to=avr@gjlay.de \
--cc=gcc-help@gcc.gnu.org \
--cc=iant@google.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).