[llvm-bugs] [Bug 46666] New: Loops with parallel metadata shouldn't assume that loads are safe to hoist out of conditionals

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Jul 9 18:50:29 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=46666

            Bug ID: 46666
           Summary: Loops with parallel metadata shouldn't assume that
                    loads are safe to hoist out of conditionals
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: wala1 at illinois.edu
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

There's an assumption/requirement that loads that are annotated inside loops
with llvm.loop.parallel_accesses metadata should be safe to hoist out of
conditionals. See, for instance LoopVectorizationLegality::blockCanBePredicated
in LoopVectorizationLegality.cpp. This requirement isn't documented in the LLVM
language reference manual page.

This bug report is to request that this requirement be removed from the code,
so that loads that are unsafe to hoist out of conditionals can still be
annotated, and hence a loop with such loads can still be considered parallel.
There are three reasons why this requirement doesn't make a lot of sense:

1) There's no logical connection between this requirement and the other meaning
of llvm.loop.parallel_accesses metadata, which is that the iterations are free
of loop-carried dependencies.
2) It makes it harder to lower code for parallel languages mapping onto LLVM
that don't have this requirement, such as OpenCL. See
https://github.com/pocl/pocl/issues/757 for an example of a potential crash
caused by this.
3) LLVM supports masked loads, which can be used as an alternative to hoisting
the load of the conditional.

The downside to removing this requirement is a potential performance impact on
existing code that makes use of it to avoid generating masked loads.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200710/0bf67c26/attachment.html>


More information about the llvm-bugs mailing list