This is an archive of the discontinued LLVM Phabricator instance.

Codegen: LICM Remove check for exactly 1 register def.
ClosedPublic

Authored by iteratee on Jun 16 2016, 1:46 PM.

Details

Summary

When considering whether to split an instruction with a memory operand
into an explicit load and a register-based instruction, we currently
check that the resulting instruction has exactly 1 def. This prevents 2
important LICM optimizations: compares with memory operands, and double
inderect calls. All the tests and the test-suite pass without the check.
My guess as to original intent is to limit the additional register pressure
created by the new instruction, but given that we only split out a single
register, it is already limited.

The licm-dominance test now checks actual memory loads for hoisting instead of
undef, and it tests compares.
hoist-invariant-load.ll now checks for 2 hoists, the intended hoist, and a bonus
from calling a got-relative function in a loop.

Diff Detail

Event Timeline

iteratee updated this revision to Diff 61021.Jun 16 2016, 1:46 PM
iteratee retitled this revision from to Codegen: LICM Remove check for exactly 1 register def..
iteratee updated this object.
iteratee added a reviewer: sunfish.
iteratee set the repository for this revision to rL LLVM.
iteratee updated this revision to Diff 61044.Jun 16 2016, 3:37 PM
iteratee removed rL LLVM as the repository for this revision.

Corrected the output of the non-hoisted loads.

iteratee added a reviewer: qcolombet.

Quentin, Andrew,

Functionally this is a one-line change. When splitting an instruction from a memory op to an explicit load and a register op, we were checking the number of register defs in the resulting register op, and bailing if it wasn't exactly one. I've thought carefully about it, and the check doesn't seem to be necessary, and the tests all pass, but I'd like someone more familiar with that code to look over it.

Thanks,
Kyle.

atrick edited edge metadata.Jun 21 2016, 6:26 PM

Frankly I don't understand what MID.getNumDefs() has to do with anything here. So your change looks ok to me. But I'm not clear on how the register form of the instruction ends up with multiple defs--I guess it already had multiple defs. Can you show an example of that in the form of machine instrs?

Sure. I should be able to find an example with multiple defs.

Andrew, there's a test with a multiple register-def instruction in D21627.
The existing tests now cover 0-def instructions, as the double-indirection for the call gets hoisted to a single indirection.

I couldn't put the test in this revision, because memory-refs were not being propagated for the folded load in the instruction in question.

atrick accepted this revision.Jun 23 2016, 2:18 PM
atrick edited edge metadata.

LGTM

This revision is now accepted and ready to land.Jun 23 2016, 2:18 PM