Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek:
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
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.
It can happen, but if it happens, that would mean user code bug, like using
register asm with an register that is unsuitable for use as global or local
register var on the target, or it could be backend bug (expansion of some
pattern clobbering register that has other fixed uses).
You shouldn't ICE on it, but what happens is undefined.
Now I have a test case where exact that happens:
- An expander needs to clobber a hard register.
- That hard reg is live at that time and *not* used as operand to the expander
- That hard reg is neither fixed nor a global register.
- That hard reg is neither used for argument passing nor for frame pointer
or stack pointer and not for any exotic use like static chain etc.
For the cases where the hard register is operand to the expander I have a
patch; is it possible to get it in 4.9.2? It fixes both ICEs and also (but not
all) wrong code situations.
AFAIKT the remaining wrong code situations are as explained above. The hard
register is assigned a const_int too early so that it gets clobbered by the
mentioned expander.
I still think that's a bug in the middle ends...
Johann
Before RA, the use of hard regs should be limited (pretty much just fixed
regs where really necessary, global and local register variables (user needs
to use with care), function arguments and return values (short lived around
the call patterns).
Jakub
