1 of 1 people found this helpful
It looks like somewhere the code you are generating is trying to add a vector of floats to a integer value(The %32 and %34 mean its the 32nd and 34th operation that is not assigned to a variable, so maybe looking there will help). This is illegal in both LLVM and OpenCL C. This is a problem with Apple's implementation and you need to report the issue to them.
Thanks for your answer, Micah.
Yes, I did figure out that the one complaint is about trying to add an i32 to a float4. Perhaps an automatic conversion previously performed by the old C->IL compiler fails in the new one, and I may be able to track it down in my (complex) kernel. I don't know what it doesn't like about "store <4 x float> %34, <4 x float>* %Y, align 16", though I could go through and comment out lines that store float4s using pointers. (Maybe it should be "align 128"....)
For now, I just need this to work, so, if I don't have much success in the beginning of the weekend, I'll go back to an earlier OS.
I don't know if I can file a bug with Apple without paying their $100 registration fee, and I hear their forums are pretty slow so don't know if it's worth it. I imagine a fix will appear in future updates....
*UPDATE*; here is a partial copy of what I've posted on the AMD board:
It turns out the error I quoted was generated by almost the first executable line in my kernel, where I was clearly adding an int32 to a float4; presumably it was auto-converted before because the numbers used to be right. Adding a (float4) cast to the int32 fixed that.
BUT, now I'm embroiled in more mysterious bugs without any cool diagnostic info; it just tells me what pass it fails on, and my only method to search it down is what I call the "méthode tédieuse", commenting out huge chunks of my kernel to see when it compiles, then cutting the chunks down, then trying again. I've identified a problem with a tweening function I've had trouble with before, and now need to find another solution for. Also, some kind of problem with stepping through a character buffer.
It now fails on the 'AMD IL Swizzle Encoder Pass', which is at least two passes later than it used to fail, but that's all it'll give me....
If I find more of a solution, I'll post it here....
*oops* I meant to say the Khronos board; that and this one seem to be the best....
It seems that what I cannot do is to use the result of the subtraction of two character pointers. If a and b are both __global char *, I cannot use (b-a) in a calculation, nor can I return (b-a) from a function. (I can say "int c = b - a" if I don't use the result, presumably because it's optimized away.) Doesn't help to use ptrdiff_t instead, casts, intermediate variables, nothing. This particular routine has worked for decades; it's my strpos function....
If I figure this out any further, I'll post again....
If you can get a simplified test case that reproduces the error, I can see if we can reproduce it on the PC side and fix it. The swizzle encoder pass is common across platforms, so the same error should show up.