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: Jakub Jelinek <jakub at redhat dot com>
- To: Georg-Johann Lay <avr at gjlay dot de>
- Cc: Jeff Law <law at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 24 Oct 2014 20:29:50 +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> <544A984D dot 8080804 at gjlay dot de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
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).