[llvm-dev] [GlobalISel] A Proposal for global instruction selection

Quentin Colombet via llvm-dev llvm-dev at lists.llvm.org
Wed Nov 18 15:12:34 PST 2015


> On Nov 18, 2015, at 3:01 PM, Matthias Braun <mbraun at apple.com> wrote:
> 
>> 
>> On Nov 18, 2015, at 1:32 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> Hi James,
>> 
>>> On Nov 18, 2015, at 11:53 AM, James Molloy <james at jamesmolloy.co.uk> wrote:
>>> 
>>> Hi Quentin,
>>> 
>>> I'm really excited to see this happening!
>>> 
>>> My major question is over the testing story for this. How are we going to write unit tests for GIR?
>> 
>> Thanks for bringing that up!
>> That is a very good question and also one that will require a lot of work to address properly.
>> 
>> Ultimately, I’d like we are able to write unit tests directly in the MachineInstr representation. Part of the goal of making the IR self contained, i.e., with no back links to LLVM IR, is to make the testing easier.
>> 
>> Now, to answer the question on how we do that, I have a pragmatic answer, though I am not proud of it:
>> We are going to write unit tests with LLVM IR as input and check the MI output of the pass, e.g.,with print-after=IRTranslator.
>> 
>> That’s not great, but at least we can test now!
> We do have the .mir dumping and reading. To me that code looks like it basically works and just might need a bug fix here and there. Should be the right thing to use when starting a new project like this, shouldn't it?

That’s the thing, I don’t want to spend time writing mir code. I basically want to be able to take the machine code I expect and add CHECK lines without going through the yaml formatting business.

For just the translator, the story might be different though, because it’s LLVM IR to MI, so maybe that’s already well supported.
Then, I haven’t followed the mir stuff closely to know whether or not it would work with “a bug fix here and there”. For instance, I don’t know how it gets the opcode for the parser, i.e., how automatic/easy it is to add the generic opcode, plus we will have to teach it how to deal with type on instructions and so on.

My impression was that it was sufficiently lacking usability so that a fresh start would make sense (basically I see it as a prototype), but you may well be right. Again, I don’t plan to look into it for the prototype timeframe, but if you are, by all means!

Cheers,
-Quentin

> 
> - Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151118/8bd6706d/attachment.html>


More information about the llvm-dev mailing list