[llvm-dev] [GlobalISel] Quick Status

[Quentin Colombet via llvm-dev]

Hi Manuel,

> On Feb 15, 2017, at 2:15 PM, Manuel Jacob <me at manueljacob.de> wrote:
> 
> 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?

Short answer, yes.

GlobalISel per se does not come with combining capabilities. It provides an instruction selection framework and you can hook up any passes you want anywhere in the pipeline, in particular to do combines.
Combine/folding are supported when selecting the instructions but right now, GlobalISel does not come with an equivalent of DAG combine. We are going to add generic support for that in the future but the core pipeline shouldn’t require it for correctness.
Note: We may leverage the existing MachineCombiner for that.

Cheers,
-Quentin

> 
> 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