[Mesa-dev] [RFC] glsl-to-llvm

[Tom Stellard]

On Tue, Sep 11, 2012 at 11:12:49PM +0200, Vincent wrote:
> Hi,
> 
> I'm currently working on a glsl to llvm pass that generates LLVM IR from
> glsl tree for drivers that ships with a LLVM backend. The current code
> is located here : http://cgit.freedesktop.org/~vlj/mesa in branch
> glsl-to-llvm3. It is still a work in progress (I'm not fully satisfied
> by some factorisation and coding style is not consistant atm)
> 
> I'm testing it against evergreen at the moment thus namespace are r600
> oriented (all the intrinsics are prefixed with llvm.AMDGPU. or
> llvm.R600.). However I'm trying to make it as driver agnostic as
> possible.

The r600 backend uses way too many intrinsics, and most of them could be
replaced with either one or a sequence of LLVM IR instructions.
However, there are several things that must be represented by intrinsics.
These include texture instructions, shader inputs, shader outputs, and
possibly others.  I think if this front end is used by multiple backends,
it will be important to come up with some standard intrinsic definitions
that backends can share.  Ideally GLSL->LLVM would not need to use any
target-specific intrinsics.

> This pass does not try to optimise the code : it does not generate MAD
> instructions, it does not propagate constant, it does not eliminate dead
> code like glsl-to-tgsi does. I chose to leave this to LLVM own pass. On
> the other hand, I try to make the result code as close as possible from
> the glsl tree : it preserves vector structure (tgsi to llvm does not),
> it does not convert boolean to int... This allows to find some bugs in
> the backend that were hidden by glsl-to-tgsi but could appear with a
> futur OpenCl support.

I think it makes sense to leave most of the optimizations to LLVM, and it
is really nice to be able to preserve type information from the
frontend.  This will make a lot of things in the backend much easier.

> On the other hand r600 backend does not like vectorised input : it
> generates much more MOV instruction than necessary. I've narrowed the
> issue : the COPY llvm internal instructions is lowered to 4 MOV even if
> following instruction overwrite some registers, and the store output
> instruction fixes the exported register, which is not optimal wrt
> register coalescing pass.
> 

Unfortunately, LLVM 3.1 won't coalesce copies from physical to virtual
registers or vice-versa.  This is a reason why it would be good to
move the import/export instructions into the backend, so we can avoid
emulating them with physical live-in and live-out registers.


> So far I managed to get something like 200 regressions on 7000 passing
> tests in piglit, but recent changes (ie moving the interpolation logic
> inside backend) added 100 others regressions in current trunk, because
> of failing front/back face color issue I'm working on.
>

Very nice!  It sounds  like you have made really good progress.

> However I meet some "standardisation" issue at the moment. I work with a
> single driver that has its own constraint and feature.
> For instance, I use a single intrinsic to export everything :
> llvm.AMDGPU.store.output. However there are some special outputs like
> vertex position and pixel color. I'm planning to add a
> llvm.AMDGPU.store.position and llvm.AMDGPU.store.color. Transform and
> Feedback also needs a similar special intrinsic.
> 

As I mentioned above, if this will be used by multiple backends, it
makes sense to rename the intrinsics to something like
llvm.mesa.store.position.

> I'd like to request your feedback and suggestion on my work.
> Glsl-to-llvm does not calls any gallium function and can also be used by
> classic dri drivers. I don't know what is the current status of the
> recently announced llvm i965 compiler, I don't know if it has already
> its own glsl-to-llvm pass or not. If not, it would be really great if
> this pass was also shared by i965, as the more drivers use it, the more
> reliable it is.
> 

It would be great to have this shared by multiple targets.  I'd be
interested to here what Intel's plans are regarding an LLVM front-end.

-Tom