This is an archive of the discontinued LLVM Phabricator instance.

MachineLoopInfo: add function findInductionRegister.
AbandonedPublic

Authored by SjoerdMeijer on Nov 29 2016, 12:39 AM.

Details

Summary

MachineLoopInfo: add function findInductionRegister. This is mainly refactored from the Hexagon backend and is intended to be NFC. This is more groundwork to recognise loop induction variables and trip counts for MachineLoops, and is related to D27191 and D27192.

Diff Detail

Event Timeline

SjoerdMeijer retitled this revision from to MachineLoopInfo: add function findInductionRegister..
SjoerdMeijer updated this object.
SjoerdMeijer added a subscriber: llvm-commits.
qcolombet added inline comments.Nov 30 2016, 1:41 PM
include/llvm/CodeGen/MachineLoopInfo.h
174

Which register would you return in such case:

///   R0 = phi ..., [ R1, LatchBlock ]
///   R1 = R0 + #bump
///   if (R1 < #N) goto loop

Is this supposed to work only on non-SSA code?

176

What do we do we more general representation?
E.g., R = R * 2
Or with R = R + RuntimeConstant?

Basically where I am going is shouldn't we have a representation a la SCEV?

kparzysz added inline comments.Nov 30 2016, 1:55 PM
include/llvm/CodeGen/MachineLoopInfo.h
174

The induction register is the one that is being "bumped", i.e. R0 in your case. This code only works on SSA.

176

Runtime constants won't work, neither will *=. This code was meant to get the typical "+= const" patterns.

Regarding the M-SCEV: yes, we should have it. What's missing is the time to do it. :)

It's been on my to-do-eventually list, and my idea was to use some sort of a common underlying representation of instructions (i.e. all add instructions for all targets would be represented as a generic "add" instruction). Now that we have GlobalISel, this groundwork is in place, we could develop some sort of a translation scheme from MIR to GIR(?), and then develop SCEV on top of that.

SjoerdMeijer added inline comments.Dec 1 2016, 1:32 AM
include/llvm/CodeGen/MachineLoopInfo.h
176

Thanks for the reviews. Yes, I agree, the recognised loops will be simple loops, and thus the approach is not very general, but it could serve some purposes though. Or now that GlobalIsel is being developed, is this technical debt that we don't want to develop further? I haven't followed the development of GlobalIsel close enough, but is it stable enough that we could be looking into SCEVs for machine instructions/GIR?

qcolombet added inline comments.Dec 20 2016, 2:13 PM
include/llvm/CodeGen/MachineLoopInfo.h
174

Thanks Krzysztof.
Could we update the comment accordingly?

176

GlobalISel simplifies some bits by providing generic opcodes with known semantic, but, by design, GlobalISel allows to mix those with target specific opcodes, so we would still need some way to retrieve the semantic of those.

Regarding the general approach, I would say this is up to you. I think it make sense to have a SCEV like framework at the machine level, I don't see how that patch helps us toward that goal though.

I think what we lack is a way to extract semantic from the instructions. GlobalISel partially solves that. The general problem is still open.

SjoerdMeijer added inline comments.Dec 21 2016, 8:15 AM
include/llvm/CodeGen/MachineLoopInfo.h
176

Regarding the general approach, I would say this is up to you.

Well, I am very much interested in your feedback. :-) What I also mean is that I don't want to have this in at all costs, or in other words, if we agree this patch is not going to help in any way then yes let's not waste time and abandon it. The way I could see this useful is that the we anyway need interfaces like this (e.g. findInductionRegister), but the implementation could different, i.e. ad-hoc at the moment, but should be done with proper MI scev analysis in the future. Perhaps this first hacky (but proven?) implementation could serve as reference when the scev analysis is developed? But again, if we think this is not the case let's abandon.
By the way, I am very interested in machine level scev analysis and think I am going to look into it soon.

qcolombet edited edge metadata.Jan 4 2017, 4:43 PM

Hi,

Thanks for your patience!

What I also mean is that I don't want to have this in at all costs, or in other words, if we agree this patch is not going to help in any way then yes let's not waste time and abandon it.

In that case, I would suggest to have a generic (Machine)Analysis pass that computes all the IVs. The way I envision this is by injecting more semantic on the target instructions. Hal suggested in another review (I don't remember which one though), that we could do that with a single API looking like bool TargetInstrInfo::isSimilarTo(const MachineInstr &MI, unsigned Opcode, SmallVectorImpl<MachineOperand *>& VRegs), where VRegs would contain the list of operands that matches Opcode behavior. We did not work out the details.
This gets possible thanks to GlobalISel that features generic opcodes that we can use as a reference (e.g., G_ADD, G_MUL, etc.).

The way we would use this API would look like:
// Check if this MI is an IV update of the form Def = Arg1 + Arg2.
SmallVector<MachineOperand *, 4> Opds;
if (TII->isSimilarTo(MI, TargetOpcode::G_ADD, Opds)) {

MachineOperand *Def = Opds[0];
MachineOperand *Arg1 = Opds[1]; 
MachineOperand *Arg2 = Opds[2];
// Check if the update is constant.
if (Arg2.isImm() || (Arg2.isReg && TII->isSimilarTo(MRI.getUniqueDef(Arg2.getReg()), G_CONSTANT, [...]))
[...]

}

Note: we may actually use something different than MachineOperand to represent similar construction but with no physical machine operand (e.g., a = b << 1 is equivalent to a = b * 2, but we don't have a MachineOperand to convey this information).

The nice thing about this direction is that we may be able to extract the semantic of some target specific instructions directly form the ISel patterns. E.g., if we have a pattern (add src1, src2) -> (ADDXrr src1, src2), we could deduce automatically that ADDXrr is similar to G_ADD.

Anyhow, there is a lot of work to be there and there may be dragons on the path!

Cheers,
-Quentin

SjoerdMeijer abandoned this revision.Jan 16 2017, 9:05 AM

Hi Quentin,
Apologies for my late reply, but thanks a lot for reviewing and for sharing your ideas/plans on this topic! I am going to follow your suggestions, will start prototyping an approach using global isel (and TII), and will abandon this patch.

Cheers,
Sjoerd.