summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/pragma-loop-safety-outer.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [CodeGen] Generate follow-up metadata for loops with more than one ↵Michael Kruse2019-04-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | transformation. Before this patch, CGLoop would dump all transformations for a loop into a single LoopID without encoding any order in which to apply them. rL348944 added the possibility to encode a transformation order using followup-attributes. When a loop has more than one transformation, use the follow-up attribute define the order in which they are applied. The emitted order is the defacto order as defined by the current LLVM pass pipeline, which is: LoopFullUnrollPass LoopDistributePass LoopVectorizePass LoopUnrollAndJamPass LoopUnrollPass MachinePipeliner This patch should therefore not change the assembly output, assuming that all explicit transformations can be applied, and no implicit transformations in-between. In the former case, WarnMissedTransformationsPass should emit a warning (except for MachinePipeliner which is not implemented yet). The latter could be avoided by adding 'llvm.loop.disable_nonforced' attributes. Because LoopUnrollAndJamPass processes a loop nest, generation of the MDNode is delayed to after the inner loop metadata have been processed. A temporary LoopID is therefore used to annotate instructions and RAUW'ed by the actual LoopID later. Differential Revision: https://reviews.llvm.org/D57978 llvm-svn: 357415
* [CodeGen] Generate llvm.loop.parallel_accesses instead of ↵Michael Kruse2018-12-201-5/+7
| | | | | | | | | | | | | | llvm.mem.parallel_loop_access metadata. Instead of generating llvm.mem.parallel_loop_access metadata, generate llvm.access.group on instructions and llvm.loop.parallel_accesses on loops. There is one access group per generated loop. This is clang part of D52116/r349725. Differential Revision: https://reviews.llvm.org/D52117 llvm-svn: 349823
* [CodeGen] Emit parallel_loop_access for each loop in the loop stack.Michael Kruse2018-08-031-0/+20
Summary: Emit !llvm.mem.parallel_loop_access metadata for memory accesses even if the parallel loop is not the top on the loop stack. Fixes llvm.org/PR37558. Reviewers: ABataev, hfinkel, amusman, tyler.nowicki Reviewed By: hfinkel Subscribers: Meinersbur, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D48808 llvm-svn: 338810
OpenPOWER on IntegriCloud