On 10/24/14 12:19, Georg-Johann Lay wrote:
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.
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).
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
code...
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.
jeff
