Archives Discussions

[josopait]

I am having some difficulties with the IL compiler. It is not very resourceful with registers. It 'optimizes' the code by keeping temporary results, by calculating stream indices long before the actual memory call, and by using only the x and y elements for double precision calculations (even if I tell it to move a result to z and w elements). As a consequence, it runs out of registers. Is there some way to turn off optimization? Or is there some other way to have more direct control over the code generation?

Ingo

[MicahVillmow]

josopait,
Is this the IL generated by brook+? Or are you looking at the ISA generated by the cal compiler? The IL generated by brook+ uses a virtual instruction set and has an unlimited register set, so there is no worries in that aspect. If you want more control over the code generation, you need to move down to programming at the CAL/IL level. That way you can see exactly what IL instructions are mapping to what ISA instructions. At the brook+ level, it is a lot harder to see what that mapping is.

[josopait]

I mean the cal compiler that compiles IL code to ISA instructions. There the maximum number of GP registers of about 125 is exceeded. The compiler then tries to swap some of the variables into scratch memory, but kernel execution fails with the error message 'Symbol "' returned by calGetErrorString(). I presumably have to pass an additional texture as scratch memory to the kernel, with a symbol name that I don't know. But I don't want to do this anyway for performance reasons. What I would like is to make the cal compiler more resourceful with GP registers, particularly for calculations in double precision.

[MicahVillmow]

If you can pm me your kernel I can look at it and see if I can shoe-horn the compiler into generating better code.