[PATCH] D116465: [SPIRV 6/6] Add 2 essential passes and the simplest tests

[Ilia Diachkov via Phabricator via llvm-commits]

iliya-diyachkov added a comment.

In D116465#3293196 <https://reviews.llvm.org/D116465#3293196>, @rengolin wrote:

> If you use a global auto-increment next_id(), there's no way VReg IDs for operations in any function will clash with previously defined types and constants (in previous functions).
>
> The VReg numbers on the later functions will be (numerically) large, but the number of different IDs in each function will still be the same, so code generation should be equally efficient.

Thanks for the explanation, now I see the whole idea and I like it in general. The following example illustrates its work.

After func1 translation:

  global_func
    %0 = OpTypeConstGVarFDecl1
  
  func1
    %0 = OpTypeConstGVarFDecl1
    ...
    %3 = OpIAdd %0 %1 %2
    ...
    %N = ...

After func2 translation:

  global_func
    %0 = OpTypeConstGVarFDecl1
    %N+1 = OpTypeConstGVarFDecl2
  
  func2
    %0 = OpTypeConstGVarFDecl1
    %N+1 = OpTypeConstGVarFDecl2
    ...
    %N+4 = OpIMul %0 %N+2 %N+3
    %N+7 = OpIAdd %N+1 %N+5 %N+6
    ...
    %M = ...

And so on... However I see several issues:

1. We probably need to operate with global_func and the current function (func1 or func2 in the example) simultaneously when we generate a new type. I'm not sure is it possible in a MachineFunctionPass.

Perhaps we would introduce a new ModulePass which generates most of type/const/gvar/fdecl instrs. But some of the instrs can be generated in CallLowering and InstructionSelector which are not module-level, so we could not modify both global_func and the current function.

2. As Aleksander wrote some virtual registers in regular functions are generated by IRTranslator and we don't directly control their numbers (normally it starts from %0).

We could use some weird (or "non-statutory") approaches for setting first NumVirtRegs in each next regular function so it will generate %N+1, %N+2  as in example. I have just implemented such one without changes in target-independent code. But since this is a non-standard thing, we cannot be sure that it will work always and reliably.

Either we could make a new method in IRTranslator that allows to start NumVirtRegs from desirable number, but it will be a target independent feature and its justification (it is unlikely that it will ever be needed for other targets), review and commit may take a noticeable time.

3. This may require a noticeable rework of the current implementation (I don't mean this patch series, but the entire backend that is in Khronos repository, because all changes we do in this patch series are implemented in the main code base at first with checking for no degradation on >200 LITs and OpenCL CTS).

So if we don't have obvious solutions for the 1st and 2nd issues, I would add this suggestion to the TODO list (we'll take it in mind during further code revisions) and go forward with the existing GlobalTypesAndRegNumPass.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116465/new/

https://reviews.llvm.org/D116465