Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Converting invoke to call does not transfer "MD_mem_parallel_loop_access" metadata #39341

Closed
llvmbot opened this issue Dec 13, 2018 · 2 comments
Labels
bugzilla Issues migrated from bugzilla

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Dec 13, 2018

Bugzilla Link 39994
Resolution FIXED
Resolved on Dec 14, 2018 10:15
Version trunk
OS Linux
Reporter LLVM Bugzilla Contributor
CC @hfinkel,@Meinersbur
Fixed by commit(s) r349170

Extended Description

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

@Meinersbur
Copy link
Member

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.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Dec 14, 2018

Great, thanks for the quick reaction!

Glad I could help,
Moritz

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Development

No branches or pull requests

2 participants