Jeff Law schrieb:
On 10/24/14 10:29, Jakub Jelinek wrote:
But I'd say, if you can't handle hard regs in the operands (either
general,
or some specific ones), you should
force the hard regs into pseudos (all hard regs, or just the problematic
ones) in the expander.
So in this case, check if they overlap with those 2 regs, and force the
input operands into pseudos if they do; the output will be harder, guess
you'd need to emit the pattern into a pseudo and emit_move_insn it
afterwards to the hard reg.
I'm pretty sure that's what Georg is going to do, my comment was that
the existence of the hard register operand _may_ point to something else
that we would want to fix.
jeff
Yes, that's the straight forward approach which works so far. Bit
tedious, but well...
In one case expmed generated different code, though: divmodhi instead of
mulhi_highpart for HI division by const_int. Cheating with costs did
not help. However for now I am mostly after correct, ICE-less code.
What I am concerned about is:
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.
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?
The point is that the middle-end could know that it is generating bad
code...
Johann
