In a recent 10.0 branch snapshot build with polly enabled, trying to use polly the way it is described in the polly man page doesn't work: $ clang -O3 -mllvm -polly test.c clang (LLVM option parsing): Unknown command line argument '-polly'. Try: 'clang (LLVM option parsing) --help' clang (LLVM option parsing): Did you mean '--color'? The problem is that the plugin isn't loaded automatically -- loading the plugin manually "fixes" it. $ clang -Xclang -load -Xclang LLVMPolly.so -O3 -mllvm -polly ~/test.c [works] Either autoload should be restored, or the polly man page should be updated to mention the plugin needs to be loaded.
Fix under review: https://reviews.llvm.org/D72372 Unfortunately, for clang-10, we probably will not cherry-pick it, for the same reasons as for https://github.com/llvm/llvm-project/issues/120. I would update the polly docs, but the website is currently not updating.
Committed as 6369b9bf311
Reopening because the issue is not solved yet for clang-10.
I can confirm that the fix works on top of the 10 branch.
Thanks for confirming!
(In reply to Michael Kruse from comment #1) > Fix under review: https://reviews.llvm.org/D72372 > > Unfortunately, for clang-10, we probably will not cherry-pick it, for the > same reasons as for https://github.com/llvm/llvm-project/issues/120. I think the fact that more fixes (D72372) are needed confirms my decision in https://github.com/llvm/llvm-project/issues/120 that this is not stable enough to be merged. > > I would update the polly docs, but the website is currently not updating. Sounds like everything is broken :(
(In reply to Hans Wennborg from comment #6) > I think the fact that more fixes (D72372) are needed confirms my decision in > https://github.com/llvm/llvm-project/issues/120 that this is not stable > enough to be merged. The commit 6369b9bf311 only changes a CMake default value to what it was in the 9.0 branch. I'd consider it relatively risk-free. An alternative would be to revert https://reviews.llvm.org/rG24ab9b537e61b3fe5e6a1019492ff6530d82a3ee in the clang-10 branch which introduced this change of default value.
> An alternative would be to revert > https://reviews.llvm.org/rG24ab9b537e61b3fe5e6a1019492ff6530d82a3ee > in the clang-10 branch which introduced this change of default value. That would be my preferred solution, except that for something which only landed in January, it has a surprising amount of changes landed on top of it, so reverting is actually hard. I looked at D72372 again, and I have to say the commit message is inscrutable to me (it talks about windows, but this is broken on linux, and about a flag which can only work when set to "on" but is "off" by default???). But the change itself doesn't look like it can do too much damage. Bernhard confirmed this fixes things on the branch, which sounds good. For the GitHub issue, you committed D74464 and D74602. Do I understand correctly that those are fixing a problem that's separate from this?
There is no dynamic module loading (`-load`) on Windows, meaning that in the default configuration, Polly was not usable on Windows. This was the first version of the patch. I should have updated the patch summary. Sorry.
(In reply to Michael Kruse from comment #9) > There is no dynamic module loading (`-load`) on Windows, meaning that in the > default configuration, Polly was not usable on Windows. This was the first > version of the patch. > > I should have updated the patch summary. Sorry. Okay, and my second question: > For the GitHub issue, you committed D74464 and D74602. Do I understand > correctly that those are fixing a problem that's separate from this?
(In reply to Hans Wennborg from comment #8) > For the GitHub issue, you committed D74464 and D74602. Do I understand > correctly that those are fixing a problem that's separate from this? (In reply to Hans Wennborg from comment #8) > For the GitHub issue, you committed D74464 and D74602. Do I understand > correctly that those are fixing a problem that's separate from this? I was not involved in these patches. They may cause merge conflicts, but solve different problems. @sguelton can tell more about them. The issues are orthogonal. D72372 only changes the default value of LLVM_POLLY_LINK_INTO_TOOLS, depending on whether Polly is on LLVM_ENABLE_PROJECTS.
Thanks for clarifying! I've cherry-picked D72372 to 10.x as d7afdb596e865c11b853d8c5df7d96d594170e1c.
(In reply to Hans Wennborg from comment #12) > Thanks for clarifying! > > I've cherry-picked D72372 to 10.x as > d7afdb596e865c11b853d8c5df7d96d594170e1c. Thank you. They actually don't merge-conflict, I was checking it after writing comment #11. When submitting the comment, Bugzilla complained because comment #10 was added while I checked whether D72372 applies cleanly on release/10.0. That's why comment #11 is messy. Sorry again for the short notice and hurry. I should have been aware of the issue much earlier and even remarked that we want to keep linking Polly statically by default during the review of an early version of D61446.