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] 
> <javascript:>> 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] <javascript:>.
>> 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.

Reply via email to