[RFC] #pragma ivdep

[Tobias Grosser]

On 03/07/2013 10:57 AM, Tobias Grosser wrote:
> 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.

We can obviously take a very conservative approach here. Meaning it 
should be enough to define the semantics of #pragma ivdeps for the cases 
where we actually introduce memory annotations and to only confirm for 
those cases, that we are in line what other compilers do.
For the 'safe start' I mentioned further down, this seems easy to do.

> 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
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits