[global-isel] Proposal for a global instruction selector

Project Infrastructure LLVM Dev List Archives
21

Sorry, looks like I cannot edit the subject line on gmail. The
question is fairly generic, so it is hopefully not too bad.

One of the nice properties of the LLVM IR is that it is complete. A FE
converts all the information it has to LLVM, and there is then no
going back to AST. This is what lets us serialize it and have language
independent tools to manipulate it.

The lower level IRs we currently use don't have that property. DAGs
and MI refer back to LLVM IR. This creates some redundancy and makes
serialization harder. It also creates problems when a pass wants to
modify information that is in the llvm IR. For example, we have a
memory leak in ARMFastISel.cpp:2194 :frowning:

So the question is if the plan is to make MI a "complete" IR, that we
can serialize independently of the LLVM IR, run a single pass on, etc.

Thanks,
Rafael

22

Yes, we should do that.

23

Absolutely, although that project is somewhat orthogonal to the design of the instruction selector.

Some back-references are pointers into IR functions, such as MBB holding a pointer to its BasicBlock and MachineMemOperand referencing a pointer Value. These references should definitely be cleaned up.

Other dependencies are more about borrowing LLVM infrastructure. For example, an EVT can reference an llvm::Type, and a MachineOperand can reference both a ConstantInt and a ConstantFP. It doesn’t seem very important to reimplement that functionality.

Thanks,
/jakob

24

Jakob Stoklund Olesen <stoklund@2pi.dk> writes:

So the question is if the plan is to make MI a "complete" IR, that we
can serialize independently of the LLVM IR, run a single pass on, etc.

Absolutely, although that project is somewhat orthogonal to the design
of the instruction selector.

Some back-references are pointers into IR functions, such as MBB
holding a pointer to its BasicBlock and MachineMemOperand referencing
a pointer Value. These references should definitely be cleaned up.

I agree a cleanup here would be great.

How would we handle machine-level alias analysis without pointer types?
MachineMemOperands and their Ptr members currently provide information
that can be used by alias analysis at the MI level. We use that quite a
bit here.

Overall I really like the direction this is heading. Thanks for
spearheading this, Jakob!

                           -David