[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