summaryrefslogtreecommitdiffstats
path: root/clang/include
Commit message (Collapse)AuthorAgeFilesLines
...
* [OPENMP]Simplify printing of declare variant attribute, NFC.Alexey Bataev2019-11-261-23/+28
|
* Partially reland "[Diagnostics] Put "deprecated copy" warnings into ↵Dávid Bolvanský2019-11-262-3/+11
| | | | | | -Wdeprecated-copy"" But do not enable it under -Wextra until libcxx issue is solved.
* Recommit ARM-NEON: make type modifiers orthogonal and allow multiple modifiers.Tim Northover2019-11-263-838/+830
| | | | | | | | | | | | | | | | | | The modifier system used to mutate types on NEON intrinsic definitions had a separate letter for all kinds of transformations that might be needed, and we were quite quickly running out of letters to use. This patch converts to a much smaller set of orthogonal modifiers that can be applied together to achieve the desired effect. When merging with downstream it is likely to cause a conflict with any local modifications to the .td files. There is a new script in utils/convert_arm_neon.py that was used to convert all .td definitions and I would suggest running it on the last downstream version of those files before this commit rather than resolving conflicts manually. The original version broke vcreate_* because it became a macro and didn't apply the normal integer promotion rules before bitcasting to a vector. This adds a temporary.
* Revert "[Diagnostic] add a warning which warns about misleading indentation"Tom Stellard2019-11-253-11/+1
| | | | | | This reverts commit 7b86188b50bf6e537fe98b326f258fbd23108b83. This commit introduced bot falures for multi-stage bots with -Werror.
* Revert "[Diagnostics] Put "deprecated copy" warnings into -Wdeprecated-copy"Tom Stellard2019-11-252-12/+3
| | | | | | This reverts commit 9353c5dd0664ea444236e527bf93566e11dc34df. This commit introduced bot falures for multi-stage bots with -Werror.
* [Diagnostic] add a warning which warns about misleading indentationTyker2019-11-253-1/+11
| | | | | | | | | | | | Summary: Add a warning for misleading indentation similar to GCC's -Wmisleading-indentation Reviewers: aaron.ballman, xbolva00 Reviewed By: aaron.ballman, xbolva00 Subscribers: arphaman, Ka-Ka, thakis Differential Revision: https://reviews.llvm.org/D70638
* Revert 3f91705ca54 "ARM-NEON: make type modifiers orthogonal and allow ↵Hans Wennborg2019-11-253-828/+837
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | multiple modifiers." This broke the vcreate_u64 intrinsic. Example: $ cat /tmp/a.cc #include <arm_neon.h> void g() { auto v = vcreate_u64(0); } $ bin/clang -c /tmp/a.cc --target=arm-linux-androideabi16 -march=armv7-a /tmp/a.cc:4:12: error: C-style cast from scalar 'int' to vector 'uint64x1_t' (vector of 1 'uint64_t' value) of different size auto v = vcreate_u64(0); ^~~~~~~~~~~~~~ /work/llvm.monorepo/build.release/lib/clang/10.0.0/include/arm_neon.h:4144:11: note: expanded from macro 'vcreate_u64' __ret = (uint64x1_t)(__p0); \ ^~~~~~~~~~~~~~~~~~ Reverting until this can be investigated. > The modifier system used to mutate types on NEON intrinsic definitions had a > separate letter for all kinds of transformations that might be needed, and we > were quite quickly running out of letters to use. This patch converts to a much > smaller set of orthogonal modifiers that can be applied together to achieve the > desired effect. > > When merging with downstream it is likely to cause a conflict with any local > modifications to the .td files. There is a new script in > utils/convert_arm_neon.py that was used to convert all .td definitions and I > would suggest running it on the last downstream version of those files before > this commit rather than resolving conflicts manually.
* [Diagnostics] Warn for comparison with string literals expanded from macro ↵Dávid Bolvanský2019-11-241-1/+1
| | | | | | | | | | | | | | | | | | (PR44064) Summary: As noted in PR, we have a poor test coverage for this warning. I think macro support was just overlooked. GCC warns in these cases. Clang missed a real bug in the code I am working with, GCC caught it. Reviewers: aaron.ballman Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70624
* Reland 'Fixed -Wdeprecated-copy warnings. NFCI.'Dávid Bolvanský2019-11-232-2/+12
| | | | Fixed hashtable copy ctor.
* Revert 'Fixed -Wdeprecated-copy warnings. NFCI.'Dávid Bolvanský2019-11-232-12/+2
| | | | pdbutil's test is failing.
* Fixed typo introduced before commiting previous patch. NFCI.Dávid Bolvanský2019-11-231-1/+1
|
* Fixed -Wdeprecated-copy warnings. NFCI.Dávid Bolvanský2019-11-232-2/+12
|
* clang/Modules: Rename CompilerInstance::ModuleManager, NFCDuncan P. N. Exon Smith2019-11-221-3/+3
| | | | | | | | | | | | | | | | | | | Fix the confusing naming of `CompilerInstance::ModuleManager`. This is actually an instance of `ASTReader`, which contains an instance of `ModuleManager`. I have to assume there was a point in the past where they were just one class, but it's been pretty confusing for a while. I think it's time to fix it. The new name is `TheASTReader`; the annoying `The` prefix is so that we don't shadow the `ASTReader` class. I tried out `ASTRdr` but that seemed less clear, and this choice matches `ThePCHContainerOperations` just a couple of declarations below. Also rename `CompilerInstance::getModuleManager` and `CompilerInstance::createModuleManager` to `*ASTReader`, making some cases of `getModuleManager().getModuleManager()` a little more clear. https://reviews.llvm.org/D70583
* clang/Modules: Refactor CompilerInstance::loadModule, NFCDuncan P. N. Exon Smith2019-11-222-14/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactor the logic on CompilerInstance::loadModule and a couple of surrounding methods in order to clarify what's going on. - Rename ModuleLoader::loadModuleFromSource to compileModuleFromSource and fix its documentation, since it never loads a module. It just creates/compiles one. - Rename one of the overloads of compileModuleImpl to compileModule, making it more obvious which one calls the other. - Rename compileAndLoadModule to compileModuleAndReadAST. This clarifies the relationship between this helper and its caller, CompilerInstance::loadModule (the old name implied the opposite relationship). It also (correctly) indicates that more needs to be done to load the module than this function is responsible for. - Split findOrCompileModuleAndReadAST out of loadModule. Besides reducing nesting for this code thanks to early returns and the like, this refactor clarifies the logic in loadModule, particularly around calls to ModuleMap::cacheModuleLoad and ModuleMap::getCachedModuleLoad. findOrCompileModuleAndReadAST also breaks early if the initial ReadAST call returns Missing or OutOfDate, allowing the last ditch call to compileModuleAndReadAST to come at the end of the function body. - Additionally split out selectModuleSource, clarifying the logic due to early returns. - Add ModuleLoadResult::isNormal and OtherUncachedFailure, so that loadModule knows whether to cache the result. OtherUncachedFailure was added to keep this patch NFC, but there's a chance that these cases were uncached by accident, through copy/paste/modify failures. These should be audited as a follow-up (maybe we can eliminate this case). - Do *not* lift the setting of `ModuleLoadFailed = true` to loadModule because there isn't a clear pattern for when it's set. This should be reconsidered in a follow-up, in case it would be correct to set `ModuleLoadFailed` whenever no module is returned and the result is either Normal or OtherUncachedFailure. - Add some header documentation where it was missing, and fix it where it was wrong. This should have no functionality change. https://reviews.llvm.org/D70556
* Remove needless Attr.h include from DeclCXX.h, NFCReid Kleckner2019-11-221-1/+0
| | | | | | This actually has no impact on the build, because TypeLoc.h includes Attr.h. However, DeclCXX.h has no need of it, so go ahead and remove it. The final step in this patch series is to split Attr.h and Attrs.h.
* Separate the MS inheritance model enum from the attribute, NFCReid Kleckner2019-11-225-30/+44
| | | | | | This avoids the need to include Attr.h in DeclCXX.h for a four-value enum. Removing the include will be done separately, since it is large and risky change.
* Move vtordisp mode from Attr class to LangOptions.h, NFCReid Kleckner2019-11-225-11/+12
| | | | | This removes one of the two uses of Attr.h in DeclCXX.h, reducing the need to include Attr.h as widely. LangOptions is already very popular.
* [Diagnostics] Put "deprecated copy" warnings into -Wdeprecated-copyDávid Bolvanský2019-11-222-3/+12
| | | | | | | | | | | | | | | | | Summary: GCC 9 added -Wdeprecated-copy (as part of -Wextra). This diagnostic is already implemented in Clang too, just hidden under -Wdeprecated (not on by default). This patch adds -Wdeprecated-copy and makes it compatible with GCC 9+. This diagnostic is heavily tested in deprecated.cpp, so I added simple tests just to check we warn when new flag/-Wextra is enabled. Reviewers: rsmith, dblaikie Reviewed By: dblaikie Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70342
* [libTooling] Add stencil combinators for nodes that may be pointers or values.Yitzhak Mandelbaum2019-11-221-0/+13
| | | | | | | | | | | | | | | | Summary: Adds combinators `maybeDeref` and `maybeAddressOf` to provide a uniform way to handle nodes which may be bound to either a pointer or a value (most often in the context of member expressions). Such polymorphism is already supported by `access`; these combinators extend it to more general uses. Reviewers: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70554
* clang/Modules: Move Serialization/Module.{h,cpp} to ModuleFile, NFCDuncan P. N. Exon Smith2019-11-213-6/+6
| | | | | | | | | Remove some cognitive load by renaming clang/Serialization/Module.h to clang/Serialization/ModuleFile.h, since it declares the ModuleFile class. This also makes editing a bit easier, since the basename of the file no long conflicts with clang/Basic/Module.h, which declares the Module class. Also move lib/Serialization/Module.cpp to lib/Serialization/ModuleFile.cpp.
* [analyzer] NFC: Don't clean up range constraints twice.Artem Dergachev2019-11-211-3/+4
| | | | | | Slightly improves static analysis speed. Differential Revision: https://reviews.llvm.org/D70150
* [OPENMP]Remove unused template parameter, NFC.Alexey Bataev2019-11-212-4/+2
|
* [OPENMP50]Add device/kind context selector support.Alexey Bataev2019-11-213-1/+30
| | | | | | | | | | | | Summary: Added basic parsing/sema support for device/kind context selector. Reviewers: jdoerfert Subscribers: rampitec, aheejin, fedor.sergeev, simoncook, guansong, s.egerton, hfinkel, kkwli0, caomhin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70245
* [OPENMP50]Add if clause in for simd directive.Alexey Bataev2019-11-211-0/+1
| | | | | | According to OpenMP 5.0, if clause can be used in for simd directive. If condition in the if clause if false, the non-vectorized version of the loop must be executed.
* [DeclCXX] Remove unknown external linkage specificationsEhud Katz2019-11-211-10/+2
| | | | | | | | | | | | | | | | Partial revert of r372681 "Support for DWARF-5 C++ language tags". The change introduced new external linkage languages ("C++11" and "C++14") which not supported in C++. It also changed the definition of the existing enum to use the DWARF constants. The problem is that "LinkageSpecDeclBits.Language" (the field that reserves this enum) is actually defined as 3 bits length (bitfield), which cannot contain the new DWARF constants. Defining the enum as integer literals is more appropriate for maintaining valid values. Differential Revision: https://reviews.llvm.org/D69935
* Fix Wshadow warning against global None variable. NFC.Simon Pilgrim2019-11-211-2/+2
|
* Atomics: support min/max orthogonallyTim Northover2019-11-212-4/+6
| | | | | | | | | | | | We seem to have been gradually growing support for atomic min/max operations (exposing longstanding IR atomicrmw instructions). But until now there have been gaps in the expected intrinsics. This adds support for the C11-style intrinsics (i.e. taking _Atomic, rather than individually blessed by C11 standard), and the variants that return the new value instead of the original one. That way, people won't be misled by trying one form and it not working, and the front-end is more friendly to people using _Atomic types, as we recommend.
* [Sema] Add a 'Semantic' parameter to Expr::isKnownToHaveBooleanValueErik Pilkington2019-11-201-1/+7
| | | | | | | | | Some clients of this function want to know about any expression that is known to produce a 0/1 value, and others care about expressions that are semantically boolean. This fixes a -Wswitch-bool regression I introduced in 8bfb353bb33c, pointed out by Chris Hamilton!
* ARM-NEON: make type modifiers orthogonal and allow multiple modifiers.Tim Northover2019-11-203-837/+828
| | | | | | | | | | | | | | The modifier system used to mutate types on NEON intrinsic definitions had a separate letter for all kinds of transformations that might be needed, and we were quite quickly running out of letters to use. This patch converts to a much smaller set of orthogonal modifiers that can be applied together to achieve the desired effect. When merging with downstream it is likely to cause a conflict with any local modifications to the .td files. There is a new script in utils/convert_arm_neon.py that was used to convert all .td definitions and I would suggest running it on the last downstream version of those files before this commit rather than resolving conflicts manually.
* ARM-NEON: separate soon-to-be conflicting f16 patterns. NFC.Tim Northover2019-11-201-2/+6
| | | | | | | | This separates some intrinsic definitions into multiple instantiations because they use a modifier that forces the float size to a given value. That modifier won't work in the new NeonEmitter modifier scheme and committing this separately allows the Python script to be run on the .td files to perform the conversion automatically.
* Wrap C APIs with pragmas enforcing -Werror=strict-prototypesDuncan P. N. Exon Smith2019-11-199-53/+75
| | | | | | | | | Force `-Werror=strict-prototypes` so that C API tests fail to compile if we add a non-prototype declaration. This should help avoid regressions like bddecba4b333f7772029b4937d2c34f9f2fda6ca was fixing. https://reviews.llvm.org/D70285 rdar://problem/57203137
* [OPENMP50]Add if clause in simd directive.Alexey Bataev2019-11-193-2/+6
| | | | | | According to OpenMP 5.0, if clause can be used in simd directive. If condition in the if clause if false, the non-vectorized version of the loop must be executed.
* [CGDebugInfo] Emit subprograms for decls when AT_tail_call is understood ↵Vedant Kumar2019-11-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (reland with fixes) Currently, clang emits subprograms for declared functions when the target debugger or DWARF standard is known to support entry values (DW_OP_entry_value & the GNU equivalent). Treat DW_AT_tail_call the same way to allow debuggers to follow cross-TU tail calls. Pre-patch debug session with a cross-TU tail call: ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` Post-patch (note that the tail-calling frame, "helper", is visible): ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f80 main`helper [opt] [artificial] frame #2: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` This was reverted in 5b9a072c because it attached declaration subprograms to inlinable builtin calls, which interacted badly with the MergeICmps pass. The fix is to not attach declarations to builtins. rdar://46577651 Differential Revision: https://reviews.llvm.org/D69743
* Add a key method to Sema to optimize debug info sizeReid Kleckner2019-11-191-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that the debug info describing the Sema class is an appreciable percentage of the total object file size of objects in Sema. By adding a key function, clang is able to optimize the debug info size by emitting a forward declaration in TUs that do not define the key function. On Windows, with clang-cl, these are the total sizes of object files in Sema before and after this change, compiling with optimizations and debug info: before: 335,012 KB after: 278,116 KB delta: -56,896 KB percent: -17.0% The effect on link time was negligible, despite having ~56MB less input. On Linux, with clang, these are the same sizes using DWARF -g and optimizations: before: 603,756 KB after: 515,340 KB delta: -88,416 KB percent: -14.6% I didn't use type units, DWARF-5, fission, or any other special flags. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D70340
* [C-index] Fix test when using Debug target & MSVC STLAlexandre Ganea2019-11-191-1/+1
| | | | | | Avoids a deadlock in "clang/test/Index/crash-recovery-modules.m" when building with the MSVC STL & _ITERATOR_DEBUG_LEVEL == 2 (meaning a DEBUG build) Differential Revision: https://reviews.llvm.org/D69959
* clang: Add -fconvergent-functions flagMatt Arsenault2019-11-193-1/+5
| | | | | | | | The CUDA builtin library is apparently compiled in C++ mode, so the assumption of convergent needs to be made in a typically non-SPMD language. The functions in the library should still be assumed convergent. Currently they are not, which is potentially incorrect and this happens to work after the library is linked.
* [NFC] Refactor representation of materialized temporariesTyker2019-11-198-71/+143
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* [libTooling] Extend `buildASTFromCodeWithArgs` to take files argument.Yitzhak Mandelbaum2019-11-191-1/+2
| | | | | | | | | | | | | | | | | Summary: Adds an optional parameter to `buildASTFromCodeWithArgs` that allows the user to pass additional files that the main code needs to compile. This change makes `buildASTFromCodeWithArgs` consistent with `runToolOnCodeWithArgs`. Patch by Alexey Eremin. Reviewers: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70175
* Work on cleaning up denormal mode handlingMatt Arsenault2019-11-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | Cleanup handling of the denormal-fp-math attribute. Consolidate places checking the allowed names in one place. This is in preparation for introducing FP type specific variants of the denormal-fp-mode attribute. AMDGPU will switch to using this in place of the current hacky use of subtarget features for the denormal mode. Introduce a new header for dealing with FP modes. The constrained intrinsic classes define related enums that should also be moved into this header for uses in other contexts. The verifier could use a check to make sure the denorm-fp-mode attribute is sane, but there currently isn't one. Currently, DAGCombiner incorrectly asssumes non-IEEE behavior by default in the one current user. Clang must be taught to start emitting this attribute by default to avoid regressions when this is switched to assume ieee behavior if the attribute isn't present.
* [clang][NFC] Make various uses of Regex constThomas Preud'homme2019-11-191-2/+1
| | | | | | | | | | | | | | | | The const-correctness of match() was fixed in rL372764, which allows uses of Regex objects to be const in cases they couldn't be before. This patch tightens up the const-ness of Regex in various such cases. Reviewers: thopre Reviewed By: thopre Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68155
* [ARM,MVE] Add intrinsics for scalar shifts.Simon Tatham2019-11-192-8/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fills in the small family of MVE intrinsics that have nothing to do with vectors: they implement bit-shift operations on 32- or 64-bit values held in one or two general-purpose registers. Most of these shift operations saturate if shifting left, and round to nearest if shifting right, although LSLL and ASRL behave like ordinary shifts. When these instructions take a variable shift count in a register, they pay attention to its sign, so that (for example) LSLL or UQRSHLL will shift left if given a positive number but right if given a negative one. That makes even LSLL and ASRL different enough from standard LLVM IR shift semantics that I couldn't see any better alternative than to simply model the whole family as a set of MVE-specific IR intrinsics. (The //immediate// forms of LSLL and ASRL, on the other hand, do behave exactly like a standard IR shift of a 64-bit value. In fact, those forms don't have ACLE intrinsics defined at all, because you can just write an ordinary C shift operation if you want one of those.) The 64-bit shifts have to be instruction-selected in C++, because they deliver two output values. But the 32-bit ones are simple enough that I could write a DAG isel pattern directly into each Instruction record. Reviewers: ostannard, MarkMurrayARM, dmgreen Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70319
* Implement __attribute__((objc_direct)), __attribute__((objc_direct_members))Pierre Habouzit2019-11-187-5/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __attribute__((objc_direct)) is an attribute on methods declaration, and __attribute__((objc_direct_members)) on implementation, categories or extensions. A `direct` property specifier is added (@property(direct) type name) These attributes / specifiers cause the method to have no associated Objective-C metadata (for the property or the method itself), and the calling convention to be a direct C function call. The symbol for the method has enforced hidden visibility and such direct calls are hence unreachable cross image. An explicit C function must be made if so desired to wrap them. The implicit `self` and `_cmd` arguments are preserved, however to maintain compatibility with the usual `objc_msgSend` semantics, 3 fundamental precautions are taken: 1) for instance methods, `self` is nil-checked. On arm64 backends this typically adds a single instruction (cbz x0, <closest-ret>) to the codegen, for the vast majority of the cases when the return type is a scalar. 2) for class methods, because the class may not be realized/initialized yet, a call to `[self self]` is emitted. When the proper deployment target is used, this is optimized to `objc_opt_self(self)`. However, long term we might want to emit something better that the optimizer can reason about. When inlining kicks in, these calls aren't optimized away as the optimizer has no idea that a single call is really necessary. 3) the calling convention for the `_cmd` argument is changed: the caller leaves the second argument to the call undefined, and the selector is loaded inside the body when it's referenced only. As far as error reporting goes, the compiler refuses: - making any overloads direct, - making an overload of a direct method, - implementations marked as direct when the declaration in the interface isn't (the other way around is allowed, as the direct attribute is inherited from the declaration), - marking methods required for protocol conformance as direct, - messaging an unqualified `id` with a direct method, - forming any @selector() expression with only direct selectors. As warnings: - any inconsistency of direct-related calling convention when @selector() or messaging is used, - forming any @selector() expression with a possibly direct selector. Lastly an `objc_direct_members` attribute is added that can decorate `@implementation` blocks and causes methods only declared there (and in no `@interface`) to be automatically direct. When decorating an `@interface` then all methods and properties declared in this block are marked direct. Radar-ID: rdar://problem/2684889 Differential Revision: https://reviews.llvm.org/D69991 Reviewed-By: John McCall
* Temporarily Revert "Add support for options -frounding-math, ftrapping-math, ↵Eric Christopher2019-11-183-36/+1
| | | | | | | | -ffp-model=, and -ffp-exception-behavior=" and a follow-up NFC rearrangement as it's causing a crash on valid. Testcase is on the original review thread. This reverts commits af57dbf12e54f3a8ff48534bf1078f4de104c1cd and e6584b2b7b2de06f1e59aac41971760cac1e1b79
* Remove useless param tag to fix Wdocumentation warning. NFCI.Simon Pilgrim2019-11-181-3/+0
|
* [ARM,MVE] Add intrinsics for vector comparisons.Simon Tatham2019-11-182-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the `vcmp` family of ACLE MVE intrinsics: vector/vector, vector/scalar, and the predicated forms of both. All are represented using standard existing IR: vector/scalar comparisons are represented by making a vector out of the scalar first, and predicated forms are represented by taking the bitwise AND of the input predicate and the output of the comparison. Existing LLVM-side tests demonstrate that ISel will pattern-match all of that back down to single MVE VCMPs. The idiom of handling a vector/scalar operation by generating IR to expand the scalar into a second vector is going to be needed for a lot of MVE intrinsics, so to make that easy, I've provided a helper function that automatically works out the element count. The comparison intrinsics are the first ones that have to //return// a predicate, in the user-facing `mve_pred16_t` format. This means we have to use the `arm_mve_pred_v2i` low-level intrinsic to convert it back from the logical `<n x i1>` form used in IR. I've done that explicitly in the code gen specification for the builtins, because it happens much more rarely in the ACLE API than passing a Predicate as input, so it didn't seem worth automating in MveEmitter. Reviewers: ostannard, MarkMurrayARM, dmgreen Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70297
* [ARM] Allocatable Global Register Variables for ARMAnna Welker2019-11-185-2/+18
| | | | | | | | | | | | Provides support for using r6-r11 as globally scoped register variables. This requires a -ffixed-rN flag in order to reserve rN against general allocation. If for a given GRV declaration the corresponding flag is not found, or the the register in question is the target's FP, we fail with a diagnostic. Differential Revision: https://reviews.llvm.org/D68862
* Revert "[NFC] Refactor representation of materialized temporaries"Nico Weber2019-11-178-141/+71
| | | | | | This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982. It broke ./ClangdTests/FindExplicitReferencesTest.All on the bots, see comments on https://reviews.llvm.org/D69360
* [NFC] Refactor representation of materialized temporariesTyker2019-11-168-71/+141
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* Remove +x permission on some filesSylvestre Ledru2019-11-161-0/+0
|
* [clang-format] Add SpaceBeforeBracketsmydeveloperday2019-11-161-2/+11
| | | | | | | | | | | | | | | | Summary: Adds a new option SpaceBeforeBrackets to add spaces before brackets (i.e. int a[23]; -> int a [23];) This is present as an option in the Visual Studio C++ code formatting settings, but there was no matching setting in clang-format. Reviewers: djasper, MyDeveloperDay, mitchell-stellar Reviewed By: MyDeveloperDay Subscribers: llvm-commits, cfe-commits, klimek Patch by: Anteru Tags: #clang, #clang-format, #llvm Differential Revision: https://reviews.llvm.org/D6920
OpenPOWER on IntegriCloud