[llvm-dev] [GlobalISel] Quick Status

[Manuel Jacob via llvm-dev]

The current code generator based on SelectionDAG has two different 
concepts: DAG node combining and instruction selection.

Will the code generator based on GlobalISel have this distinction as 
well?

On 2017-01-21 02:19, Quentin Colombet via llvm-dev wrote:
> Hi all,
> 
> Following the thread from
> 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).
> 
> 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