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: Georg-Johann Lay <avr at gjlay dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 24 Oct 2014 20:19:57 +0200
- 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>
Jeff Law schrieb:
On 10/24/14 10:29, Jakub Jelinek wrote:
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.
But I'd say, if you can't handle hard regs in the operands (either
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.
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