summaryrefslogtreecommitdiffstats
path: root/clang/test/Parser/pragma-loop-safety.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Append new attributes to the end of an AttributeList.Michael Kruse2018-08-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
* Revert "Append new attributes to the end of an AttributeList."Michael Kruse2018-06-251-4/+4
| | | | | | | This reverts commit r335084 as requested by David Jones and Eric Christopher because of differences of emitted warnings. llvm-svn: 335516
* Append new attributes to the end of an AttributeList.Michael Kruse2018-06-191-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse, and therefore printed in the wrong order by -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effects, especially for diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attribute's order was changed instead. It also causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reversed. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway, which often is on the same line. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 335084
* Add loop pragma for Loop DistributionAdam Nemet2016-06-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is similar to other loop pragmas like 'vectorize'. Currently it only has state values: distribute(enable) and distribute(disable). When one of these is specified the corresponding loop metadata is generated: !{!"llvm.loop.distribute.enable", i1 true/false} As a result, loop distribution will be attempted on the loop even if Loop Distribution in not enabled globally. Analogously, with 'disable' distribution can be turned off for an individual loop even when the pass is otherwise enabled. There are some slight differences compared to the existing loop pragmas. 1. There is no 'assume_safety' variant which makes its handling slightly different from 'vectorize'/'interleave'. 2. Unlike the existing loop pragmas, it does not have a corresponding numeric pragma like 'vectorize' -> 'vectorize_width'. So for the consistency checks in CheckForIncompatibleAttributes we don't need to check it against other pragmas. We just need to check for duplicates of the same pragma. Reviewers: rsmith, dexonsmith, aaron.ballman Subscribers: bob.wilson, cfe-commits, hfinkel Differential Revision: http://reviews.llvm.org/D19403 llvm-svn: 272656
* Add new llvm.loop.unroll.enable metadata for use with "#pragma unroll".Mark Heffernan2015-08-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | This change adds the new unroll metadata "llvm.loop.unroll.enable" which directs the optimizer to unroll a loop fully if the trip count is known at compile time, and unroll partially if the trip count is not known at compile time. This differs from "llvm.loop.unroll.full" which explicitly does not unroll a loop if the trip count is not known at compile time With this change "#pragma unroll" generates "llvm.loop.unroll.enable" rather than "llvm.loop.unroll.full" metadata. This changes the semantics of "#pragma unroll" slightly to mean "unroll aggressively (fully or partially)" rather than "unroll fully or not at all". The motivating example for this change was some internal code with a loop marked with "#pragma unroll" which only sometimes had a compile-time trip count depending on template magic. When the trip count was a compile-time constant, everything works as expected and the loop is fully unrolled. However, when the trip count was not a compile-time constant the "#pragma unroll" explicitly disabled unrolling of the loop(!). Removing "#pragma unroll" caused the loop to be unrolled partially which was desirable from a performance perspective. llvm-svn: 244467
* Add assume_safety option for pragma loop vectorize and interleave.Tyler Nowicki2015-06-111-0/+34
Specifying #pragma clang loop vectorize(assume_safety) on a loop adds the mem.parallel_loop_access metadata to each load/store operation in the loop. This metadata tells loop access analysis (LAA) to skip memory dependency checking. llvm-svn: 239572
OpenPOWER on IntegriCloud