summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [Clang FE, SystemZ] Recognize -mrecord-mcount CL option.Jonas Paulsson2019-12-191-0/+26
| | | | | | | | | | Recognize -mrecord-mcount from the command line and add a function attribute "mrecord-mcount" when passed. Only valid on SystemZ (when used with -mfentry). Review: Ulrich Weigand https://reviews.llvm.org/D71627
* [WebAssembly] Add avgr_u intrinsics and require nuw in patternsThomas Lively2019-12-181-0/+14
| | | | | | | | | | | | | | | | | | Summary: The vector pattern `(a + b + 1) / 2` was previously selected to an avgr_u instruction regardless of nuw flags, but this is incorrect in the case where either addition may have an unsigned wrap. This CL changes the existing pattern to require both adds to have nuw flags and adds builtin functions and intrinsics for the avgr_u instructions because the corrected pattern is not representable in C. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71648
* [Clang FE, SystemZ] Don't add "true" value for the "mnop-mcount" attribute.Jonas Paulsson2019-12-181-2/+2
| | | | | | | | Let the "mnop-mcount" function attribute simply be present or non-present. Update SystemZ backend as well to use hasFnAttribute() instead. Review: Ulrich Weigand https://reviews.llvm.org/D71669
* Add support for the MS qualifiers __ptr32, __ptr64, __sptr, __uptr.Amy Huang2019-12-181-0/+51
| | | | | | | | | | | | | | | | | | | | Summary: This adds parsing of the qualifiers __ptr32, __ptr64, __sptr, and __uptr and lowers them to the corresponding address space pointer for 32-bit and 64-bit pointers. (32/64-bit pointers added in https://reviews.llvm.org/D69639) A large part of this patch is making these pointers ignore the address space when doing things like overloading and casting. https://bugs.llvm.org/show_bug.cgi?id=42359 Reviewers: rnk, rsmith Subscribers: jholewinski, jvesely, nhaehnle, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71039
* [FPEnv] Remove unnecessary rounding mode argument for constrained intrinsicsUlrich Weigand2019-12-171-18/+18
| | | | | | | | | | | | | | | | | | | The following intrinsics currently carry a rounding mode metadata argument: llvm.experimental.constrained.minnum llvm.experimental.constrained.maxnum llvm.experimental.constrained.ceil llvm.experimental.constrained.floor llvm.experimental.constrained.round llvm.experimental.constrained.trunc This is not useful since the semantics of those intrinsics do not in any way depend on the rounding mode. In similar cases, other constrained intrinsics do not have the rounding mode argument. Remove it here as well. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D71218
* [Clang FE, SystemZ] Recognize -mpacked-stack CL optionJonas Paulsson2019-12-171-0/+11
| | | | | | | | | | | Recognize -mpacked-stack from the command line and add a function attribute "mpacked-stack" when passed. This is needed for building the Linux kernel. If this option is passed for any other target than SystemZ, an error is generated. Review: Ulrich Weigand https://reviews.llvm.org/D71441
* Reland [NFC-I] Remove hack for fp-classification builtinsErich Keane2019-12-171-1/+11
| | | | | | | | | | | | | | | | | | The FP-classification builtins (__builtin_isfinite, etc) use variadic packs in the definition file to mean an overload set. Because of that, floats were converted to doubles, which is incorrect. There WAS a patch to remove the cast after the fact. THis patch switches these builtins to just be custom type checking, calls the implicit conversions for the integer members, and makes sure the correct L->R casts are put into place, then does type checking like normal. A future direction (that wouldn't be NFC) would consider making conversions for the floating point parameter legal. Note: The initial patch for this missed that certain systems need to still convert half to float, since they dont' support that type.
* [WebAssembly] Setting export_name implies llvm.usedSam Clegg2019-12-161-0/+2
| | | | | | | This change updates the clang front end to add symbols to llvm.used when they have explicit export_name attribute. Differential Revision: https://reviews.llvm.org/D71493
* [WebAssembly] Replace SIMD int min/max builtins with patternsThomas Lively2019-12-161-84/+0
| | | | | | | | | | | | | | | | | | Summary: The instructions were originally implemented via builtins and intrinsics so users would have to explicitly opt-in to using them. This was useful while were validating whether these instructions should have been merged into the spec proposal. Now that they have been, we can use normal codegen patterns, so the intrinsics and builtins are no longer useful. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71500
* Fix floating point builtins to not promote float->doubleErich Keane2019-12-162-1/+72
| | | | | | | | | | | As brought up in D71467, a group of floating point builtins automatically promoted floats to doubles because they used the variadic builtin tag to support an overload set. The result is that the parameters were treated as a variadic pack, which always promots float->double. This resulted in the wrong answer being given in cases with certain values of NaN.
* [ARM][MVE][Intrinsics] All vqdmulhq/vqrdmulhq tests should be for signed ↵Mark Murray2019-12-132-18/+18
| | | | | | numbers. Fix broken tests. I can't yet explain how they worked locally pre-commit.
* [ARM][MVE] Add vector reduction intrinsics with two vector operandsMikhail Maltsev2019-12-133-0/+2313
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds intrinsics for the following MVE instructions: * VABAV * VMLADAV, VMLSDAV * VMLALDAV, VMLSLDAV * VRMLALDAVH, VRMLSLDAVH Each of the above 4 groups has a corresponding new LLVM IR intrinsic, since the instructions cannot be easily represented using general-purpose IR operations. Reviewers: simon_tatham, ostannard, dmgreen, MarkMurrayARM Reviewed By: MarkMurrayARM Subscribers: merge_guards_bot, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71062
* [ARM][MVE] Add intrinsics for more immediate shifts.Simon Tatham2019-12-131-0/+915
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fills in the remaining shift operations that take a single vector input and an immediate shift count: the `vqshl`, `vqshlu`, `vrshr` and `vshll[bt]` families. `vshll[bt]` (which shifts each input lane left into a double-width output lane) is the most interesting one. There are separate MC instruction ids for shifting by exactly the input lane width and shifting by less than that, because the instruction encoding is so completely different for the lane-width special case. So I had to write two sets of patterns to match based on the immediate shift count, which involved adding a ComplexPattern matcher to avoid the general-case pattern accidentally matching the special case too. For that family I've made sure to add an llc codegen test for both versions of each instruction. I'm experimenting with a new strategy for parametrising the isel patterns for all these instructions: adding extra fields to the relevant `Instruction` subclass itself, which are ignored by the Tablegen backends that generate the MC data, but can be retrieved from each instance of that instruction subclass when it's passed as a template parameter to the multiclass that generates its isel patterns. A nice effect of that is that I can fill in those informational fields using `let` blocks, rather than having to type them out once per instruction at `defm` time. (As a result, quite a lot of existing instruction `def`s are reindented by this patch, so it's clearer to read with whitespace changes ignored.) Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71458
* [ARM][MVE][Intrinsics] Add *_x() variants of my *_m() intrinsics.Mark Murray2019-12-1319-26/+1386
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Better use of multiclass is used, and this helped find some existing bugs in the predicated VMULL* intrinsics, which are now fixed. The refactored VMULL[TB]Q_(INT|POLY)_M() intrinsics were discovered to have an argument ("inactive") with incorrect type, and this required a fix that is included in this whole patch. The argument "inactive" should have been the same width (per vector element) as the return type of the intrinsic, but was not in the case where the return type was double the element width of the input types. To assist in testing the multiclassing , and to thwart further gremlins, the unit tests are improved in scope. The *.ll tests are all generated by a small bit of throw-away scripting from the corresponding *.c tests, and as such the diffs are large and nasty. Look at the file rather than the diff. Reviewers: dmgreen, miyuki, ostannard, simon_tatham Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71421
* [clang] Turn -fno-builtin flag into an IR AttributeGuillaume Chatelet2019-12-122-30/+31
| | | | | | | | | | | | | | Summary: This is a follow up on https://reviews.llvm.org/D61634#1742154 to turn the clang driver -fno-builtin flag into an IR attribute. I also investigated pushing the attribute earlier on (in Sema) but it looks like this patch is simple and will cover all function calls. Reviewers: aaron.ballman, courbet Subscribers: cfe-commits, tejohnson Tags: #clang Differential Revision: https://reviews.llvm.org/D71193
* [ARM][CMSE] Add CMSE header and builtinsMomchil Velikov2019-12-123-0/+138
| | | | | | | | | | | | This is patch C2 as mentioned in RFC http://lists.llvm.org/pipermail/cfe-dev/2019-March/061834.html This adds CMSE builtin functions, and introduces arm_cmse.h header which has useful macros, functions, and data types for end-users of CMSE. Patch by Javed Absar. Diferential Revision: https://reviews.llvm.org/D70817
* [WebAssembly] Add new `export_name` clang attribute for controlling wasm ↵Sam Clegg2019-12-111-0/+11
| | | | | | | | | | | | | | | | | | | | export names This is equivalent to the existing `import_name` and `import_module` attributes which control the import names in the final wasm binary produced by lld. This maps the existing This attribute currently requires a string rather than using the symbol name for a couple of reasons: 1. Avoid confusion with static and dynamic linking which is based on symbol name. Exporting a function from a wasm module using this directive is orthogonal to both static and dynamic linking. 2. Avoids name mangling. Differential Revision: https://reviews.llvm.org/D70520
* CodeGen: Allow annotations on globals in non-zero address spaceNicolai Hähnle2019-12-111-4/+10
| | | | | | | | | | | | | | | | | | | | | | Summary: Attribute annotations are recorded in a special global composite variable that points to annotation strings and the annotated objects. As a restriction of the LLVM IR type system, those pointers are all pointers to address space 0, so let's insert an addrspacecast when the annotated global is in a non-0 address space. Since this addrspacecast is only reachable from the global annotations object, this should allow us to represent annotations on all globals regardless of which addrspacecasts are usually legal for the target. Reviewers: rjmccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71208
* [ARM][MVE] Add intrinsics for immediate shifts. (reland)Simon Tatham2019-12-111-0/+722
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the family of `vshlq_n` and `vshrq_n` ACLE intrinsics, which shift every lane of a vector left or right by a compile-time immediate. They mostly work by expanding to the IR `shl`, `lshr` and `ashr` operations, with their second operand being a vector splat of the immediate. There's a fiddly special case, though. ACLE specifies that the immediate in `vshrq_n` can take values up to //and including// the bit size of the vector lane. But LLVM IR thinks that shifting right by the full size of the lane is UB, and feels free to replace the `lshr` with an `undef` half way through the optimization pipeline. Hence, to keep this legal in source code, I have to detect it at codegen time. Logical (unsigned) right shifts by the element size are handled by simply emitting the zero vector; arithmetic ones are converted into a shift of one bit less, which will always give the same output. In order to do that check, I also had to enhance the tablegen MveEmitter so that it can cope with converting a builtin function's operand into a bare integer to pass to a code-generating subfunction. Previously the only bare integers it knew how to handle were flags generated from within `arm_mve.td`. Reviewers: dmgreen, miyuki, MarkMurrayARM, ostannard Reviewed By: dmgreen, MarkMurrayARM Subscribers: echristo, hokein, rdhindsa, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71065
* Recommit "[DWARF5] Start emitting DW_AT_dwo_name when -gdwarf-5 is specified."Sourabh Singh Tomar2019-12-112-8/+32
| | | | | | | | Reviewers: dblaikie, aprantl, probinson Tags: #debug-info #llvm Differential Revision: https://reviews.llvm.org/D71185
* Revert "[DWARF5] Start emitting DW_AT_dwo_name when -gdwarf-5 is specified."Sourabh Singh Tomar2019-12-112-32/+8
| | | | | This reverts commit 6ef01588f4d75ef43da4ed2a37ba7a8b8daab259. Missing Differetial revision.
* [DWARF5] Start emitting DW_AT_dwo_name when -gdwarf-5 is specified.Sourabh Singh Tomar2019-12-112-8/+32
|
* Fix bug 44190 - wrong code with #pragma pack(1)Yaxun (Sam) Liu2019-12-101-0/+23
| | | | | | | | | | | https://github.com/llvm/llvm-project/commit/5b330e8d6122c336d81dfd11c864e6c6240a381e caused a regression on s390: https://bugs.llvm.org/show_bug.cgi?id=44190 we need to copy if if either the argument is non-byval or the argument is underaligned. Differential Revision: https://reviews.llvm.org/D71282
* [FPEnv] clang support for constrained FP builtinsKevin P. Neal2019-12-101-0/+150
| | | | | | | | Change the IRBuilder and clang so that constrained FP intrinsics will be emitted for builtins when appropriate. Only non-target-specific builtins are affected in this patch. Differential Revision: https://reviews.llvm.org/D70256
* [ARM][MVE] Refactor complex vector intrinsics [NFCI]Mikhail Maltsev2019-12-102-66/+66
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch refactors instruction selection of the complex vector addition, multiplication and multiply-add intrinsics, so that it is now based on TableGen patterns rather than C++ code. It also changes the first parameter (halving vs non-halving) of the arm_mve_vcaddq IR intrinsic to match the corresponding instruction encoding, hence it requires some changes in the tests. The patch addresses David's comment in https://reviews.llvm.org/D71190 Reviewers: dmgreen, ostannard, simon_tatham, MarkMurrayARM Reviewed By: dmgreen Subscribers: merge_guards_bot, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71245
* [DebugInfo] Support to emit debugInfo for extern variablesYonghong Song2019-12-104-0/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extern variable usage in BPF is different from traditional pure user space application. Recent discussion in linux bpf mailing list has two use cases where debug info types are required to use extern variables: - extern types are required to have a suitable interface in libbpf (bpf loader) to provide kernel config parameters to bpf programs. https://lore.kernel.org/bpf/CAEf4BzYCNo5GeVGMhp3fhysQ=_axAf=23PtwaZs-yAyafmXC9g@mail.gmail.com/T/#t - extern types are required so kernel bpf verifier can verify program which uses external functions more precisely. This will make later link with actual external function no need to reverify. https://lore.kernel.org/bpf/87eez4odqp.fsf@toke.dk/T/#m8d5c3e87ffe7f2764e02d722cb0d8cbc136880ed This patch added clang support to emit debuginfo for extern variables with a TargetInfo hook to enable it. The debuginfo for the extern variable is emitted only if that extern variable is referenced in the current compilation unit. Currently, only BPF target enables to generate debug info for extern variables. The emission of such debuginfo is disabled for C++ at this moment since BPF only supports a subset of C language. Emission with C++ can be enabled later if an appropriate use case is identified. -fstandalone-debug permits us to see more debuginfo with the cost of bloated binary size. This patch did not add emission of extern variable debug info with -fstandalone-debug. This can be re-evaluated if there is a real need. Differential Revision: https://reviews.llvm.org/D70696
* Remove implicit conversion that promotes half to other larger precision ↵Jim Lin2019-12-101-1/+25
| | | | | | | | | | | | | | | | | | | | types for fp classification builtins Summary: It shouldn't promote half to double or any larger precision types for fp classification builtins. Because fp classification builtins would get incorrect result with promoted argument. For example, __builtin_isnormal with a subnormal half value should return false, but it is not. That the subnormal half value is promoted to a normal double value. Reviewers: aaron.ballman Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71049
* Revert "[ARM][MVE] Add intrinsics for immediate shifts."Eric Christopher2019-12-091-722/+0
| | | | | | | | | | | | | | and two follow-on commits: one warning fix and one functionality. As it's breaking at least the lto bot: http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/15132/steps/test-stage1-compiler/logs/stdio This reverts commits: 8d70f3c933a5b81a87a5ab1af0e3e98ee2cd7c67 ff4dceef9201c5ae3924e92f6955977f243ac71d d97b3e3e65cd77a81b39732af84a1a4229e95091
* [ARM][MVE][Intrinsics] Add VQADDQ, VHADDQ, VRHADDQ, VQSUBQ, VHSUBQ, ↵Mark Murray2019-12-097-0/+665
| | | | | | | | | | | | | | VQDMULHQ, VQRDMULHQ intrinsics. Summary: Add VQADDQ, VHADDQ, VRHADDQ, VQSUBQ, VHSUBQ, VQDMULHQ, VQRDMULHQ intrinsics and unit tests. Reviewers: simon_tatham, ostannard, dmgreen, miyuki Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71198
* [ARM][MVE][Intrinsics] Add VMULL[BT]Q_(INT|POLY) intrinsics.Mark Murray2019-12-092-0/+250
| | | | | | | | | | | | Summary: Add VMULL[BT]Q_(INT|POLY) intrinsics and unit tests. Reviewers: simon_tatham, ostannard, dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71066
* [ARM][MVE] Add intrinsics for immediate shifts.Simon Tatham2019-12-091-0/+722
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds the family of `vshlq_n` and `vshrq_n` ACLE intrinsics, which shift every lane of a vector left or right by a compile-time immediate. They mostly work by expanding to the IR `shl`, `lshr` and `ashr` operations, with their second operand being a vector splat of the immediate. There's a fiddly special case, though. ACLE specifies that the immediate in `vshrq_n` can take values up to //and including// the bit size of the vector lane. But LLVM IR thinks that shifting right by the full size of the lane is UB, and feels free to replace the `lshr` with an `undef` half way through the optimization pipeline. Hence, to keep this legal in source code, I have to detect it at codegen time. Logical (unsigned) right shifts by the element size are handled by simply emitting the zero vector; arithmetic ones are converted into a shift of one bit less, which will always give the same output. In order to do that check, I also had to enhance the tablegen MveEmitter so that it can cope with converting a builtin function's operand into a bare integer to pass to a code-generating subfunction. Previously the only bare integers it knew how to handle were flags generated from within `arm_mve.td`. Reviewers: dmgreen, miyuki, MarkMurrayARM, ostannard Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71065
* Fix build bot fails due to the patch here:Zahira Ammarguellat2019-12-091-0/+1
| | | | | https://reviews.llvm.org/D70691 Fixed the LIT test case. Added the REQUIRES instruction.
* [ARM][MVE] Add complex vector intrinsicsMikhail Maltsev2019-12-094-0/+1642
| | | | | | | | | | | | | | | | | | | | Summary: This patch adds intrinsics for the following MVE instructions: * VCADD, VHCADD * VCMUL * VCMLA Each of the above 3 groups has a corresponding new LLVM IR intrinsic. Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen Reviewed By: MarkMurrayARM Subscribers: merge_guards_bot, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71190
* Fix for build bot failure. For more details see:Zahira Ammarguellat2019-12-091-5/+5
| | | | | https://reviews.llvm.org/D70691 Upated LIT test.
* Revert "[Sema][X86] Consider target attribute into the checks in ↵Reid Kleckner2019-12-061-32/+0
| | | | | | | | | validateOutputSize and validateInputSize." This reverts commit e1578fd2b79fe5af5f80c0c166a8abd0f816c022. It introduces a dependency on Attr.h which I am removing from ASTContext.h.
* [Sema][X86] Consider target attribute into the checks in validateOutputSize ↵Craig Topper2019-12-061-0/+32
| | | | | | | | | | | | | | | | and validateInputSize. The validateOutputSize and validateInputSize need to check whether AVX or AVX512 are enabled. But this can be affected by the target attribute so we need to factor that in. This patch copies some of the code from CodeGen to create an appropriate feature map that we can pass to the function. Probably need some refactoring here to share more code with Codegen. Is there a good place to do that? Also need to support the cpu_specific attribute as well. Differential Revision: https://reviews.llvm.org/D68627
* Fix for PR44000. Optimization record for bytecode input missing.Zahira Ammarguellat2019-12-061-0/+15
| | | | Review is here: https://reviews.llvm.org/D70691
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-052-0/+70
| | | | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder. In the 2nd attempt to reapply there was a windows lit test fail, the tests were fixed to use wildcard matching. Differential Revision: https://reviews.llvm.org/D62731
* Revert " Reapply af57dbf12e54 "Add support for options ↵Melanie Blower2019-12-042-70/+0
| | | | | | | -frounding-math, ftrapping-math, -ffp-model=, and -ffp-exception-behavior="" This reverts commit cdbed2dd856c14687efd741c2d8321686102acb8. Build break on Windows (lit fail)
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-042-0/+70
| | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder Differential Revision: https://reviews.llvm.org/D62731
* [ARM][MVE][Intrinsics] Add VMULH/VRMULH intrinsics.Mark Murray2019-12-042-0/+190
| | | | | | | | | | | | Summary: Add MVE VMULH/VRMULH intrinsics and unit tests. Reviewers: simon_tatham, ostannard, dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70948
* [clang][CodeGen] Make use of cc1 instead of clang in the testsKadir Cetinkaya2019-12-031-1/+4
|
* FileCheck IR output for blockaddress in new testReid Kleckner2019-12-021-2/+6
| | | | Minor improvement to a test added in 1ac700cdef787383ad49a
* [AArch64] Attempt to fixup test line. NFCDavid Green2019-12-021-1/+3
| | | | | | The test is complaining on some of the builders. This attempts to adjust the run line to be more line the others in the same folder, using clang_cc1 as opposed to the driver.
* [ARM,MVE] Add intrinsics to deal with predicates.Simon Tatham2019-12-021-0/+290
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit adds the `vpselq` intrinsics which take an MVE predicate word and select lanes from two vectors; the `vctp` intrinsics which create a tail predicate word suitable for processing the first m elements of a vector (e.g. in the last iteration of a loop); and `vpnot`, which simply complements a predicate word and is just syntactic sugar for the `~` operator. The `vctp` ACLE intrinsics are lowered to the IR intrinsics we've already added (and which D70592 just reorganized). I've filled in the missing isel rule for VCTP64, and added another set of rules to generate the predicated forms. I needed one small tweak in MveEmitter to allow the `unpromoted` type modifier to apply to predicates as well as integers, so that `vpnot` doesn't pointlessly convert its input integer to an `<n x i1>` before complementing it. Reviewers: ostannard, MarkMurrayARM, dmgreen Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70485
* [ARM][AArch64] Complex addition Neon intrinsics for Armv8.3-AVictor Campos2019-12-022-0/+114
| | | | | | | | | | | | | | | | | | | Summary: Add support for vcadd_* family of intrinsics. This set of intrinsics is available in Armv8.3-A. The fp16 versions require the FP16 extension, which has been available (opt-in) since Armv8.2-A. Reviewers: t.p.northover Reviewed By: t.p.northover Subscribers: t.p.northover, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70862
* [ARM][MVE][Intrinsics] Add VMINQ/VMAXQ/VMINNMQ/VMAXNMQ intrinsics.Mark Murray2019-12-024-0/+326
| | | | | | | | | | Summary: Add VMINQ/VMAXQ/VMINNMQ/VMAXNMQ intrinsics and their predicated versions. Add unit tests. Subscribers: kristof.beyls, hiraditya, dmgreen, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70829
* [mips] Check that features required by built-ins are enabledSimon Atanasyan2019-11-292-2/+4
| | | | | | | | | | | | Now Clang does not check that features required by built-in functions are enabled. That causes errors in the backend reported in PR44018. This patch fixes this bug by checking that required features are enabled. This should fix PR44018. Differential Revision: https://reviews.llvm.org/D70808
* [CodeGen] Fix clang crash on aggregate initialization of array of labelsJohannes Altmanninger2019-11-281-0/+6
| | | | | | | | | | | | | | | Summary: Fix PR43700 The ConstantEmitter in AggExprEmitter::EmitArrayInit was initialized with the CodeGenFunction set to null, which caused the crash. Also simplify another call, and make the CGF member a const pointer since it is public but only assigned in the constructor. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70302
* [clang][CodeGen] Implicit Conversion Sanitizer: handle increment/decrement ↵Roman Lebedev2019-11-2710-0/+1557
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (PR44054)(take 2) Summary: Implicit Conversion Sanitizer is *almost* feature complete. There aren't *that* much unsanitized things left, two major ones are increment/decrement (this patch) and bit fields. As it was discussed in [[ https://bugs.llvm.org/show_bug.cgi?id=39519 | PR39519 ]], unlike `CompoundAssignOperator` (which is promoted internally), or `BinaryOperator` (for which we always have promotion/demotion in AST) or parts of `UnaryOperator` (we have promotion/demotion but only for certain operations), for inc/dec, clang omits promotion/demotion altogether, under as-if rule. This is technically correct: https://rise4fun.com/Alive/zPgD As it can be seen in `InstCombineCasts.cpp` `canEvaluateTruncated()`, `add`/`sub`/`mul`/`and`/`or`/`xor` operators can all arbitrarily be extended or truncated: https://github.com/llvm/llvm-project/blob/901cd3b3f62d0c700e5d2c3f97eff97d634bec5e/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp#L1320-L1334 But that has serious implications: 1. Since we no longer model implicit casts, do we pessimise their AST representation and everything that uses it? 2. There is no demotion, so lossy demotion sanitizer does not trigger :] Now, i'm not going to argue about the first problem here, but the second one **needs** to be addressed. As it was stated in the report, this is done intentionally, so changing this in all modes would be considered a penalization/regression. Which means, the sanitization-less codegen must not be altered. It was also suggested to not change the sanitized codegen to the one with demotion, but i quite strongly believe that will not be the wise choice here: 1. One will need to re-engineer the check that the inc/dec was lossy in terms of `@llvm.{u,s}{add,sub}.with.overflow` builtins 2. We will still need to compute the result we would lossily demote. (i.e. the result of wide `add`ition/`sub`traction) 3. I suspect it would need to be done right here, in sanitization. Which kinda defeats the point of using `@llvm.{u,s}{add,sub}.with.overflow` builtins: we'd have two `add`s with basically the same arguments, one of which is used for check+error-less codepath and other one for the error reporting. That seems worse than a single wide op+check. 4. OR, we would need to do that in the compiler-rt handler. Which means we'll need a whole new handler. But then what about the `CompoundAssignOperator`, it would also be applicable for it. So this also doesn't really seem like the right path to me. 5. At least X86 (but likely others) pessimizes all sub-`i32` operations (due to partial register stalls), so even if we avoid promotion+demotion, the computations will //likely// be performed in `i32` anyways. So i'm not really seeing much benefit of not doing the straight-forward thing. While looking into this, i have noticed a few more LLVM middle-end missed canonicalizations, and filed [[ https://bugs.llvm.org/show_bug.cgi?id=44100 | PR44100 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=44102 | PR44102 ]]. Those are not specific to inc/dec, we also have them for `CompoundAssignOperator`, and it can happen for normal arithmetics, too. But if we take some other path in the patch, it will not be applicable here, and we will have most likely played ourselves. TLDR: front-end should emit canonical, easy-to-optimize yet un-optimized code. It is middle-end's job to make it optimal. I'm really hoping reviewers agree with my personal assessment of the path this patch should take.. This originally landed in 9872ea4ed1de4c49300430e4f1f4dfc110a79ab9 but got immediately reverted in cbfa237892e55b7129a1178c9b03f26683d643af because the assertion was faulty. That fault ended up being caused by the enum - while there will be promotion, both types are unsigned, with same width. So we still don't need to sanitize non-signed cases. So far. Maybe the assert will tell us this isn't so. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44054 | PR44054 ]]. Refs. https://github.com/google/sanitizers/issues/940 Reviewers: rjmccall, erichkeane, rsmith, vsk Reviewed By: erichkeane Subscribers: mehdi_amini, dexonsmith, cfe-commits, #sanitizers, llvm-commits, aaron.ballman, t.p.northover, efriedma, regehr Tags: #llvm, #clang, #sanitizers Differential Revision: https://reviews.llvm.org/D70539
OpenPOWER on IntegriCloud