diff options
author | Hal Finkel <hfinkel@anl.gov> | 2016-04-26 02:00:36 +0000 |
---|---|---|
committer | Hal Finkel <hfinkel@anl.gov> | 2016-04-26 02:00:36 +0000 |
commit | 411d31ad72456ba88c0b0bee0faba2b774add65f (patch) | |
tree | 8e9ef065530d87813786258ac5e0e8989c1635a7 /llvm/docs/LangRef.rst | |
parent | 0da4442f14d0be466090821bf85cca56e1a27da9 (diff) | |
download | bcm5719-llvm-411d31ad72456ba88c0b0bee0faba2b774add65f.tar.gz bcm5719-llvm-411d31ad72456ba88c0b0bee0faba2b774add65f.zip |
[LoopVectorize] Don't consider conditional-load dereferenceability for marked parallel loops
I really thought we were doing this already, but we were not. Given this input:
void Test(int *res, int *c, int *d, int *p) {
for (int i = 0; i < 16; i++)
res[i] = (p[i] == 0) ? res[i] : res[i] + d[i];
}
we did not vectorize the loop. Even with "assume_safety" the check that we
don't if-convert conditionally-executed loads (to protect against
data-dependent deferenceability) was not elided.
One subtlety: As implemented, it will still prefer to use a masked-load
instrinsic (given target support) over the speculated load. The choice here
seems architecture specific; the best option depends on how expensive the
masked load is compared to a regular load. Ideally, using the masked load still
reduces unnecessary memory traffic, and so should be preferred. If we'd rather
do it the other way, flipping the order of the checks is easy.
The LangRef is updated to make explicit that llvm.mem.parallel_loop_access also
implies that if conversion is okay.
Differential Revision: http://reviews.llvm.org/D19512
llvm-svn: 267514
Diffstat (limited to 'llvm/docs/LangRef.rst')
-rw-r--r-- | llvm/docs/LangRef.rst | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index e9762f69f40..0612d360558 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -4716,7 +4716,8 @@ The ``llvm.mem.parallel_loop_access`` metadata refers to a loop identifier, or metadata containing a list of loop identifiers for nested loops. The metadata is attached to memory accessing instructions and denotes that no loop carried memory dependence exist between it and other instructions denoted -with the same loop identifier. +with the same loop identifier. The metadata on memory reads also implies that +if conversion (i.e. speculative execution within a loop iteration) is safe. Precisely, given two instructions ``m1`` and ``m2`` that both have the ``llvm.mem.parallel_loop_access`` metadata, with ``L1`` and ``L2`` being the |