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

[Eric Christopher via llvm-dev]

Hi Quentin,

>
>
> *** Goals ***
>
> The high level goals of the new instruction selector are:
> - Global instruction selector.
> - Fast instruction selector.
>

Are these separate or the same? It reads like two instruction selectors at
the moment.


> - Shared code path for fast and good instruction selection.
>

But then I'm not sure starting here.


> - IR that represents ISA concepts better.
> - More flexible instruction selector.
>

Some definitions here would be good.


> - Easier to maintain/understand framework, in particular legalization.
> - Self contained machine representation, no back links to LLVM IR.
> - No change to LLVM IR.
>
>
These sound great. Would be good to get the assumptions of the legalization
pass written down more explicitly as you go through this.


> *** Proposed Approach ***
>
> In this section, I describe the approach I plan to pursue in the prototype
> and the roadmap to get there. The final design will flow out of it.
>
> For this prototype, we purposely exclude any work to improve or use
> TableGen or
>

I'm getting the idea that you really don't want to work on TableGen? ;)


>
> ** Implications **
>
> As part of the bring-up of the prototype, we need to extend some of the
> core MachineInstr-level APIs:
>   - Need to remember FastMath flags for each MachineInstr.
>

Not orthogonal to this proposal? I don't mind lumping it in as being able
to do this is probably a good goal for the prototype at least, but it seems
like being able to do this is something that could be done incrementally as
a separate project?


> At the end of M1, the prototype will not be able to produce code, since we
> would only have the beginning of the Global ISel pipeline. Instead, we will
> test the IRTranslator on the generic output that is produced from the
> tested IR.
>
>
So this would be targeting Generic MachineInstr? (Better name perhaps?).
Which means that it should be serializable and testable in isolation yes?


> * Design Decisions *
>
> - The IRTranslator is a final class. Its purpose is to move away from LLVM
> IR to MachineInstr world *[final]*.
> - Lower the ABI as part of the translation process *[final]*.
>
> * Design Questions the Prototype Addresses at the End of M1 *
>
> - Handling of aggregate types during the translation.
> - Lowering of switches.
> - What about Module pass for Machine pass?
>

Could you elaborate a bit more here?


> - Introduce new APIs to have a clearer separation between:
>   - Legalization (setOperationAction, etc.)
>   - Cost/Combine related (isXXXFree, etc.)
>   - Lowering related (LowerFormal, etc.)
> - What is the contract with the backends? Is it still “should be able to
> select any valid LLVM IR”?
>

Probably :)

As far as the prototype I think you also need to address a few additional
things:

a) Calls
 Calls are probably the most important part of any new instruction selector
and lowering machinery and I think that the design of the call lowering
infrastructure is going to be a critical part of evaluating the prototype.
You might have meant this earlier when you said Lowering related, but I
wanted to make sure to call it out explicitly.

b) Testing
 It's been covered a bit before, but being able to serialize and use for
testing the various IR constructs is important. In particular, I worry
about the existing MIR code as I and a few others have tried to use it for
testcases and failed. I'm very interested in whatever ideas you have here,
all of mine are much more invasive than I think we'd like.

Thanks for tackling this project and being willing to put this out there
for discussion and feedback. I'm looking forward to the code and future
design.

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