[LLVMdev] Parallel Loop Metadata

Pekka Jääskeläinen pekka.jaaskelainen at tut.fi
Tue Feb 12 13:41:25 PST 2013


Hi,

Here it is, just synched against the latest LLVM trunk. Shall I commit this
now?


After committing, it could be worth some planning what is the best way to
provide an easy to use mechanism to "refresh" the parallel loop mem
access metadata (llvm.mem.parallel_loop_access) after optimizations that do not
render the loop to a serial one. Some kind of helper function should be
added to make it as easy as possible.

E.g., if the inliner inlines a call to a parallel loop's body, how can it
easily and robustly refresh the parallel loop metadata to the inlined function?
It needs to annotate only the new memory instructions in the loop with the
parallel mem metadata, but not any of the old ones as there might
have been a parallel-loop-unaware pass before that has added mem instructions
without the metadata. Thus, we cannot just blindly refresh the whole parallel
loop with the parallel mem access metadata after the pass finishes.

On 02/12/2013 08:12 PM, Nadav Rotem wrote:
>
> On Feb 12, 2013, at 9:02 AM, Tobias Grosser <tobias at grosser.es> wrote:
>
>> On 02/12/2013 05:54 PM, Nadav Rotem wrote:
>>>
>>>> I have the feeling option 2) does not work for you, but I don't yet
>>>> understand your reasons.
>>>
>>> My inclination to prefer #1 is due to its simplicity. But, if #1 does not
>>> work because it creates a correctness problems then #2 is the only option
>>> that is left on the table.
>>
>> Unfortunately. :-(
>>
>> Does your reply mean you agree that option 2) should be taken?
>
> Yes. I think that there is a consensus that this is the right approach.
>
>> In case you do, how should we proceed? Should Pekka submit his patch for a
>> final pre-commit review?
>
> I think so. Pekka's patch from Jan 31st looks good to me.  The is bug in the
> metadata handling in the vectorizer that we don't check that the load/store
> annotation matches the loop metadata.
>
>>
>> If option 2) is OK, Paul could also try to produce this metadate from his
>> #pragma ivdep parser.
>>
>
> That would be wonderful.
>
> Thanks, Nadav
>


-- 
--Pekka

-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-3.3-parallel-loop-metadata.patch
Type: text/x-diff
Size: 18027 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130212/453fb427/attachment.patch>


More information about the llvm-dev mailing list