Sorry for the late response. I agree with Matt that it looks like a bug. I was checking our test suit and I found a test, which does exactly what you've described with the struct wrapper. So probably we are probably missing the very simple test.
I don't think that something changed in the latest release with respect to this bug. Could you file a bug for that? On Fri, Apr 26, 2019 at 10:51 AM Brian Green <[email protected]> wrote: > The issue fixes itself if I wrap the int in a struct. > > #ifdef USE_STRUCT > struct Point { > int x; > }; > #endif > > export void > run() > { > #ifdef USE_STRUCT > varying Point p[programCount]; > for (uniform int i = 0; i < programCount; ++i) { > p[i].x = i * programCount + programIndex; > print("% --> %, %\n", &p[i], p[i].x); > } > > varying Point * varying a = &p[0]; > print("%\n", a); > varying Point * varying av = a; > print("%\n", av); > varying Point aDeref = *a; > varying Point avDeref = *av; > print("%\n", aDeref.x); > print("%\n", avDeref.x); > #else > varying int p[programCount]; > for (uniform int i = 0; i < programCount; ++i) { > p[i] = i * programCount + programIndex; > print("%\n", p[i]); > } > > varying int * uniform a = &p[0]; > print("%\n", a); > varying int * varying av = a; > print("%\n", av); > varying int aDeref = *a; > varying int avDeref = *av; > print("%\n", aDeref); > print("%\n", avDeref); > #endif > > } > > ispc test.ispc --target=sse2-i32x4 -o test_ispc.o -h test_ispc.h > -DUSE_STRUCT > 0x7fff144ab7c0 --> [0,1,2,3], > 0x7fff144ab7d0 --> [4,5,6,7], > 0x7fff144ab7e0 --> [8,9,10,11], > 0x7fff144ab7f0 --> [12,13,14,15], > [0x7fff144ab7c0,0x7fff144ab7c0,0x7fff144ab7c0,0x7fff144ab7c0] > [0x7fff144ab7c0,0x7fff144ab7c0,0x7fff144ab7c0,0x7fff144ab7c0] > [0,1,2,3] > [0,1,2,3] > > vs > > ispc test.ispc --target=sse2-i32x4 -o test_ispc.o -h test_ispc.h > [0,1,2,3] > [4,5,6,7] > [8,9,10,11] > [12,13,14,15] > 0x7ffc84759520 > [0x7ffc84759520,0x7ffc84759520,0x7ffc84759520,0x7ffc84759520] > [0,1,2,3] > [0,0,0,0] > > > > That may explain why I haven't encountered this issue in the past. > Usually our varying types are wrapped in some sort of struct. I don't have > immediate access to one of the newer versions of ISPC, but I will try with > an updated ISPC version at some point. > > -Brian > > > On Friday, April 26, 2019 at 6:44:46 AM UTC-7, Matt Pharr wrote: >> >> Hmmm.. As far as I can tell, that's a bug in ispc. >> >> To summarize: a uniform pointer to varying data is a single scalar >> pointer, but when it's dereferenced, because it's pointing to varying data, >> there's an implicit indexing by programIndex. (Alternatively, it's a vector >> load.) A varying pointer to varying data is a per-program instance pointer >> that, when dereferenced, should also have that implicit indexing applied. >> (In a sense, each program instance only sees its own instance of the >> varying data.) >> >> I *think* that it's intended for a varying pointer to varying data to >> have the same address value, as you're seeing here, and that then the bug >> is in the code emitted to dereference *av. I am a little surprised that >> that would be broken, though (surely that's in the test suite), so there >> may be something wrong in the analysis above. >> >> Thanks, >> Matt >> >> >> On Thu, Apr 25, 2019 at 12:10 PM Brian Green <[email protected]> >> wrote: >> >>> I'm running a simple test case that makes me question my understanding >>> of how varying types are created when varying pointers to varying types are >>> dereferenced. My understanding was that each pointer would be dereferenced >>> with the appropriate lane. But this appears to not be the case. >>> >>> Consider: >>> >>> export void >>> run() >>> { >>> varying int p[programCount]; >>> for (uniform int i = 0; i < programCount; ++i) { >>> p[i] = i * programCount + programIndex; >>> print("%\n", p[i]); >>> } >>> >>> varying int * uniform a = &p[0]; >>> print("%\n", a); >>> varying int * varying av = a; >>> print("%\n", av); >>> varying int aDeref = *a; >>> varying int avDeref = *av; >>> print("%\n", aDeref); >>> print("%\n", avDeref); >>> } >>> >>> >>> Compiled with ispc-1.9.2 as: >>> ispc test.ispc --target=sse2-i32x4 -o test_ispc.o -h test_ispc.h >>> >>> The following output is produced: >>> [0,1,2,3] >>> [4,5,6,7] >>> [8,9,10,11] >>> [12,13,14,15] >>> 0x7ffd8568d240 >>> [0x7ffd8568d240,0x7ffd8568d240,0x7ffd8568d240,0x7ffd8568d240] >>> [0,1,2,3] >>> [0,0,0,0] >>> >>> The avDeref value suprises me. I was expecting [0,1,2,3]. In other >>> words, the pointer in lane 0 would be dereferenced for lane 0, the pointer >>> in lane 1 would be dereferenced at lane 1, etc... But instead all of them >>> seem to be dereferenced for lane 0. I've tested this with avx1-i32x8 and >>> avx2-i32x8 and seen similar results. So, what am I misunderstanding about >>> varying pointers to varying types? >>> >>> Thanks, >>> -Brian >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Intel SPMD Program Compiler Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "Intel SPMD Program Compiler Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Intel SPMD Program Compiler Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
