[LLVMdev] [Mesa3d-dev] Folding vector instructions

Corbin Simpson mostawesomedude at gmail.com
Tue Dec 30 19:03:37 PST 2008


Zack Rusin wrote:
>> Sure, it would be very reasonable to make these target-specific
>> builtins when targeting a GPU, the same way we have target-specific
>> builtins for SSE.
> 
> Actually currently the plan is to have essentially a "two pass" LLVM IR. I 
> wanted the first one to never lower any of the GPU instructions so we'd have 
> intrinsics or maybe even just function calls like gallium.lit, gallium.dot, 
> gallium.noise and such. Then gallium should query the driver to figure out 
> which instructions the GPU supports and runs our custom llvm lowering pass 
> that decomposes those into things the GPU supports. Essentially I'd like to 
> make as many complicated things in gallium as possible to make the GPU llvm 
> backends in drivers as simple as possible and this would help us make the 
> pattern matching in the generator /a lot/ easier (matching gallium.lit vs 9+ 
> instructions it would be be decomposed to) and give us a more generic GPU 
> independent layer above. But that hasn't been done yet, I hope to be able to 
> write that code while working on the OpenCL implementation for Gallium.

Um, whichever. Honestly, I'm gonna do s/R300VS/R300FS/g on my current
work, commit it, and then forget about for the next two months while I
get a pipe working. I've got a skeleton that does nothing, and I won't
do anything else until we're solid on how to proceed. I'm definitely not
very experienced in this area, so I defer to you all.

R300 Radeons have insts that operate on vectors, and insts that operate
only on the .w of each operand. I don't know how to best represent them.

So far, the strange (read: non-LLVM) things seem to be:

- No pointers.
- No traditional load and store concepts.
- Only one type, v4f32.
- No modifiable stack, no frame pointers, no calling conventions.
- No variable-length loops.

I can tell you for sure that the ATI HLSL compiler unwinds and unrolls
everything, so that they don't have to deal with call and ret. Other
than that, I don't know how to handle this stuff.

~ C.



More information about the llvm-dev mailing list