This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR63633: May middle-end come up width hard regs for insn expanders?

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.


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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]