This is the mail archive of the
mailing list for the GCC project.
Re: PR63633: May middle-end come up width hard regs for insn expanders?
- From: Jeff Law <law at redhat dot com>
- To: Georg-Johann Lay <avr at gjlay dot de>
- Cc: Jakub Jelinek <jakub at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 24 Oct 2014 13:23:31 -0600
- Subject: Re: PR63633: May middle-end come up width hard regs for insn expanders?
- Authentication-results: sourceware.org; auth=none
- References: <544A5C14 dot 5030607 at gjlay dot de> <544A7CFA dot 700 at redhat dot com> <20141024162919 dot GL10376 at tucnak dot redhat dot com> <544A7EE5 dot 1040303 at redhat dot com> <544A984D dot 8080804 at gjlay dot de>
On 10/24/14 12:19, Georg-Johann Lay wrote:
This shouldn't be happening, the compiler certainly isn't going to set
up something like this without the user doing something horribly wrong
(see Jakub's reply).
1) May it happen that a value lives in a hard-reg across the expander?
The expander has no means to detect that situation and interfere, e.g.
hard-reg = source_value // middle-end
expand-code // back-end
sink_value = hard-reg // middle-end
where "expand-code" is one defind_expand / define_insn that clobbers /
changes (parts of) hard-reg but does *not* get hard-reg as operand. This
is wrong code obviously.
There's no need for you to try and detect this.
2) May later, non-strict-rtl passes also come up with such situations,
e.g. as they are using the same middle-end functions to emit their code?
One example is expmed.c:expand_divmod() which is called from RTL loop
optimizers (and stumbles upon PR59559 btw.)
What if no new pseudos are available at that time?
You can create new pseudos pretty much up until register allocation begins.
So, assume you can create a pseudo unless can_create_pseudo() returns
false. If you have a case where an input is a hard reg and there's an
overlapping clobber and !can_create_pseudo_p, then you could ICE or go
to heroic measures to generate code (creating stack slots, shoving
values into the stack slots, generate code, restore from stack slots,
deallocate stack). Choice really depends on the validity of the input
As Jakub states, except for parameter passing it's best to avoid
explicitly mentioned hard registers until allocation. I've never looked
closely at your port, but you might even consider creating a register
class for the set of registers you need to clobber, then clobber a
pseudo of that class. That can often help register allocation.