[llvm-dev] [GlobalISel] Quick Status

[Sean Silva via llvm-dev]

Ah, I see you mentioned it briefly here:
https://youtu.be/6tfb344A7w8?t=15m25s
And it is also mentioned here:
http://llvm.org/docs/GlobalISel.html#machineverifier

-- Sean Silva

On Sat, 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? 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.
>
> 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.
>
>
> -- Sean Silva
>
> On Fri, Jan 20, 2017 at 5:19 PM, Quentin Colombet via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> Following the thread from http://lists.llvm.org/pipermai
>> l/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).
>>
>> 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
>> 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/20170121/9cdef3ff/attachment.html>