[llvm-dev] TwoAddressInstructionPass::isProfitableToConv3Addr()

[Quentin Colombet via llvm-dev]

Hi Jonas,

> On Sep 29, 2015, at 2:00 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> I have cases of instruction pairs, where one is cheaper 2-address, and the other 3-address. I would like to select the 2-addr instruction during isel, but use the 3-addr instruction to avoid a copy if possible. I find that TwoAddressInstructionPass::isProfitableToConv3Addr() is only checking
> for the case of a physreg copy, and so leaves the majority of cases as they are (2-address).
> 
> I would like to say "If 3-addr version would avoid a copy, use it!". Does anyone else have a similar situation?

I think this is what it is supposed to do right now :). Though I reckon the test is probably over conservative in the sense that it returns true only if it can prove this is going to save a copy.

> 
> To do this, one would need to check the kill-flag on the tied use operand. If it is not killed, one can assume that the use and dst registers overlap, and therefore the copy is needed for the two-address form. The kill flags would however need to be recomputed by TwoAddr pass, since
> LiveVariables clear them.
> 
> An alternative approach might be to have something like TII->handleMachineFunctionPostCoalescer() at the end of RegisterCoalescer.cpp::runOnMachineFunction(). There, one could look for instructions and query live intervals for overlap. This hook might also be useful for other things, since this is the point just before mi-sched/regalloc, where one could do things like estimate register pressure.
> 
> Any comments on this anyone?

We could try to fix the check in two-address pass first. I believe a hook like you describe might be useful but this is yet another thing to teach the coalescer, which is already complex enough IMO. Moreover, I like the separation of concerns that 2- and 3-addr conversions are made within a dedicated pass.
That being said, if getting the best code involves teaching the coalescer about this transformation, sure!

Cheers,
Q.

> 
> /Jonas Paulsson
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev