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?

On 10/24/14 12:19, Georg-Johann Lay wrote:

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.
This shouldn't be happening, the compiler certainly isn't going to set up something like this without the user doing something horribly wrong (see Jakub's reply).

There's no need for you to try and detect this.

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?
You can create new pseudos pretty much up until register allocation begins.

So, assume you can create a pseudo unless can_create_pseudo() returns false. If you have a case where an input is a hard reg and there's an overlapping clobber and !can_create_pseudo_p, then you could ICE or go to heroic measures to generate code (creating stack slots, shoving values into the stack slots, generate code, restore from stack slots, deallocate stack). Choice really depends on the validity of the input code...

As Jakub states, except for parameter passing it's best to avoid explicitly mentioned hard registers until allocation. I've never looked closely at your port, but you might even consider creating a register class for the set of registers you need to clobber, then clobber a pseudo of that class. That can often help register allocation.


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