LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 39994 - Converting invoke to call does not transfer "MD_mem_parallel_loop_access" metadata
Summary: Converting invoke to call does not transfer "MD_mem_parallel_loop_access" met...
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Transformation Utilities (show other bugs)
Version: trunk
Hardware: PC Linux
: P enhancement
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-13 05:45 PST by Moritz Kreutzer
Modified: 2018-12-14 10:15 PST (History)
3 users (show)

See Also:
Fixed By Commit(s): r349170


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Kreutzer 2018-12-13 05:45:26 PST
Hi,

We have observed a problem with vectorization and the newest LLVM/Clang trunk (older versions seem to be affected as well). We have a loop with a potential race condition for which we force vectorization using "#pragma clang loop vectorize(assume_safety)." Despite that, Clang fails to vectorize our loop reporting that it "cannot identify array bounds." After investigating the IR after each pass, we found a potential cause of this issue. It seems like the "MD_mem_parallel_loop_access" metadata did not get transferred over when converting an invoke to a call. We could fix the problem by adding the following line to the changeToCall() method in Local.cpp:

NewCall->copyMetadata(*II, LLVMContext::MD_mem_parallel_loop_access);

This is similar to to what is done in SROA, but we are not sure whether this is a valid fix for the observed issue.

Please note that we are aware of the WIP under D52116 and D52117, but our fix (with additional copying of "LLVMContext::MD_access_group" in the same call) was also required to get the loop vectorized after applying those two patches.


Thanks,
Moritz
Comment 1 Michael Kruse 2018-12-13 12:56:47 PST
Any component that transforms IR should specify which flags/metadata are preserved or otherwise know how to use the information from the source instruction(s). This was obviously forgotten here.

I created a patch with you suggestion:

https://reviews.llvm.org/D55666

D52116/D52117 try to solve the problem that the loop is losing its link to (all of) its instructions, whereas here it is the instruction losing its association to the loop. In D52116, I added preserving MD_access_group whenever MD_mem_parallel_loop_access is preserved. Once committed, I will need to add it to D55666 as well.
Comment 2 Moritz Kreutzer 2018-12-13 23:20:28 PST
Great, thanks for the quick reaction! 

Glad I could help,
Moritz