[RFC] #pragma ivdep

[Tobias Grosser]

On 03/07/2013 12:35 AM, Redmond, Paul wrote:
>
> On 2013-03-06, at 3:42 PM, Pekka Jääskeläinen wrote:
>
>> Hi Paul,
>>
>> On 03/06/2013 10:11 PM, Redmond, Paul wrote:
>>> I have updated the patch to not add metadata on loads and stores where the
>>> pointer comes from an alloca. I wonder if the check should be more
>>> conservative and only include pointers coming from Arguments and GlobalValues
>>> (perhaps Constants too?)
>>
>> I think it's safer that way around for now.
>
> Hmm.. I'm not sure that this approach (or my original) is general enough. Here's a simple loop and the corresponding IR as generated by clang:

Before taking decisions on what exactly we need to do during code 
generation, I would appreciate if we could write down the exact 
semantics of #pragma ivdep on the C level. We should get a list of 
interesting test cases and investigate what other compilers gcc and icc 
do in such cases. Pekka and me gave a couple of test cases, that may be 
a good start.

Regarding your current approach. I wonder if, instead of analyzing the 
IR that clang generates, we could take decisions according to how
a certain memory access is/was represented at the C level. This is the 
level the #pragma ivdep semantics are defined and this should allow us 
to take the right conclusions.

A safe start would e.g. be to only annotate loads/stores that come from
array style memory accesses ala 'A[i][j]', where A was declared outside
of the loop that was marked with #pragma ivdep.

Cheers,
Tobi