[llvm-dev] [GlobalISel] Quick Status

[Quentin Colombet via llvm-dev]

Hi Sean,

> On Jan 21, 2017, at 11:19 PM, Sean Silva <chisophugis at gmail.com> wrote:
> 
> Hi Quentin,
> 
> My understanding is that throughout the GISel lowering process all the lowering steps use the same underlying MI representation, but have different invariants at different points in time (for example, G_ opcodes may be present at some point but it would be an "assert" failure to see them at other points). Are there currently any plans (or things already implemented) to verify that these invariants hold at different points throughout the lowering pipeline?

Yes, right now, the related invariants are checked at the beginning of each GISel core pass. Long-term the checks will be moved into the machine verifier but right now, given GISel is an optional library, we can’t move those checks, unless we put ifdef… which we want to avoid.

> Also, in order to run passes in isolation, ideally they would have nice, easily-understandable failure modes if you feed them MIR with invariants they don't expect.

This is expressed via some properties on the MachineFunction (property that should be dynamically computed ideally, but are not for now). We have isLegalized, isRegBankSelected, and so on.
If you run a pass on a function that doesn’t have the right property, the machine verifier will complain about it (with something along the line of expected property blabla).

> 
> The reason I bring this up is that at work I'm currently working on a compiler (not llvm-based) which does its lowering on a single IR and this is one of the most consistent pain points. In LLVM we already have this problem in the form of e.g. pre-RA and post-RA MI, but it seems like GISel is going to magnify this significantly.

Let us know if you see cases where this is not going to be enough or see ways to improve this.

Cheers,
-Quentin
> 
> 
> -- Sean Silva
> 
> On Fri, Jan 20, 2017 at 5:19 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi all,
> 
> Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html <http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html>, I am sending this email to give a status on GlobalISel progress and situation.
> 
> We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on.
> 
> As explained during the last developer meeting, we are aiming at enabling GISel by default for AArch64 at -O0 for this year (See http://llvm.org/devmtg/2016-11/#talk16 <http://llvm.org/devmtg/2016-11/#talk16>).
> 
> Note: That does not mean the design is settle nor that we won’t change the APIs.
> Note: A lot of the things listed in this email is a reminder of what we said during the dev meeting talk.
> 
> *** High Level View ***
> 
> As of r292481, we compile and run correctly with GISel (without fall back to SDISel) 63% of the LLVM test suite. If you are interested in detailed numbers, please see the attachments (courtesy of Kristof Beyls).
> 
> Note: The compile time numbers are probably noisy (compiled in parallel on the same machine), and not relevant at this point of the project anyway.
> 
> 
> *** Per Pass Status ***
> 
> ** IRTranslator **
> 
> Mostly done.
> 
> * What’s Left? *
> 
> Some instructions are not yet supported.
> 
> 
> ** Legalizer **
> 
> Core logic is present.
> 
> * What’s Left? *
> 
> - A lot of instructions are missing, in particular the vector ones.
> - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex cases.
> 
> Note: The lack of broad vector support is one on the reason we target O0, i.e., the vectorizer doesn’t run and we are less likely to hit the missing implementation.
> 
> 
> ** RegBankSelect **
> 
> - Core logic is present, no optimizations yet, or more accurately, the greedy mode is still pretty silly.
> - TableGen support for RegisterBanks description.
> 
> * What’s Left *
> 
> - TableGen the instruction mapping from the existing SDISel patterns.
> - Improve the optimization heuristic.
> 
> 
> ** InstructionSelect **
> 
> - Core logic present.
> - TableGen support for simple SDISel patterns (i.e., GISel reuses SDISel patterns)
> 
> * What’s Left *
> 
> - Teach TableGen how to reuse more complex patterns:
> — Patterns with combines in them (e.g., (mull (add)) => madd)
> — Patterns with complex patterns (e.g., SelectAddressModXR0)
> 
> 
> *** On Going Work ***
> 
> - General approach: use AArch64 O0 on the LLVM test suite as a driving vehicle to guide what to support next in the various passes.
> - Extend TableGen support to reuse more and more SDISel patterns.
> - ARM port.
> - AMDGPU port.
> - X86 port.
> 
> If you have questions, don’t hesitate!
> 
> Cheers,
> -Quentin
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 

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