[LLVMdev] Vector swizzling and write masks code generation

Zack Rusin zack at tungstengraphics.com
Thu Sep 27 06:54:10 PDT 2007


Hey,

as some of you may know we're in process of experimenting with LLVM in 
Gallium3D (Mesa's new driver model), where LLVM would be used both in the 
software only (by just JIT executing shaders) and hardware (drivers will 
implement LLVM code-generators) cases.

While the software only case is pretty straight forward I just realized I 
missed something in my initial evaluation. 

That is graphics hardware (basically every single programmable gpu) has 
instruction level support for vector swizzling and write masks.

For example the following represents a valid gpu shader instruction:
ADD dst.xyz   src1.yxzw  src2.zwxy
which performs an addition that stores the result to the dst operated (each 
operarand is a vector type of four data elements) The instruction uses source 
swizzle modifiers and destination mask modifier.

So if a language is capable of expressing such constructs (as GLSL, HLSL and 
few others are) I'd like to make sure that the code generator is actually 
capable of generating instructions with exactly those semantics. 

Right now vector operations utilizing swizzling and write masks in LLVM IR 
have to expressed with series of load/extractelement/instertelement/store 
constructs. As in 

vec2 = vec4.xy 

would end up being:
%tmp = load <4 x float>* @vec4
%tmp1 = extractelement <4 x float> %tmp, i32 0
%tmp2 = insertelement <2 x float> undef, float %tmp1, i32 0
%tmp3 = extractelement <4 x float> %tmp, i32 1
%tmp4 = insertelement <2 x float> %tmp2, float %tmp3, i32 1	
store <2 x float> %tmp4, <2 x float>* @vec2
or the like.

So I think my options come down to:

1) figure out a way of having code generator be actually able to combine all 
those IR instructions back into 
OP dst.writemask src1.swizzle1 src2.swizzle2

2) have some kind of instruction level support for it in LLVM IR

With my limited knowledge of code generators in LLVM I don't see a way of 
doing #1 and I'm afraid #2 might be the only option.
I'd appreciate any ideas and/or comments that could potentially help to solve 
this problem.

z



More information about the llvm-dev mailing list