[LLVMdev] [global-isel] Proposal for a global instruction selector

Jakob Stoklund Olesen stoklund at 2pi.dk
Mon Aug 12 09:44:25 PDT 2013


On Aug 12, 2013, at 9:24 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

> On 8 August 2013 19:18, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>> I am hoping that this proposal will generate a lot of feedback, and there
>> are many different topics to discuss. When replying to this email, please
>> change the subject header to something more specific, but keep the
>> [global-isel] tag.
> 
> 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 :-(
> 
> 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.

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





More information about the llvm-dev mailing list