- User Since
- Aug 18 2016, 4:39 AM (230 w, 4 d)
This unfortunately breaks a bunch of existing projects. I'll abandon the change for now, as the gains are probably not worth the cost of breaking backwards compatibility.
This surfaced in more fuzzier invocations, I went ahead and submitted a fix that avoids adding empty/tombstone keys when adding new interleave group members: 83aa93e99542
This ensures that the Clang loop pragma vectorize_predicate([enable|disable]) is ignored
when vectorize_width(1) is also used, since that effectively disables vectorization.
IIUC this is similar to the handling of partial overwrites in DSE (https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp#L548)?
Sat, Jan 16
Fri, Jan 15
enable vectorization unconditionally, to be in line with the behavior in LTOBackend.cpp.
Do not infer willreturn for __memcpy_chk.
Thu, Jan 14
I think this looks good now. I am planning to submit the patch tomorrow or so, unless there are further comments.
Updated to skip self-reads and simplified the code a bit.
Wed, Jan 13
I am not too familiar with how calls are handled in the X86 backend. I would really appreciate any pointers to cases that this approach might miss.
Rebased after f638c2eb4ee6d0a0bd0e80cd305ad93e382db8f5, which removed the anonymous namespace (it just included function definitions), thanks for the tip!
We have found that the calls to verifyFunction can take up to 66% of the time spent in llvm::LoopVectorizePass::processLoop. For some source files, verifyFunction took around 10% of the total compile time.
Tue, Jan 12
Thanks for taking a look!
Address comments, also add NumWillReturn stats counter and Function::willReturn()/Function::setWillReturn.
The logic in general seems fine to me, but I'm not too familiar with the attributor internals, so it would be good for someone more familiar to take a look.
Mon, Jan 11
Thanks! Addressed the nit and also added an option to limit the number of memory accesses to explore, to avoid excessive compile-times in degenerate cases
Rebase & ping :)
Sun, Jan 10
Thanks for putting up the patch!
Great, thanks for taking a look and the very helpful comments!
Sat, Jan 9
rebase after parent patch landed.
Fri, Jan 8
FWIW I think it would be good to have a bit more details in the description for changes such as this, like a link to the public docs for the extension.
Sent mail to llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-January/147678.html), to get thoughts on the 'speculatively create IR and throw away if not needed` pattern in general
rebase on top of the recent changes.