summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExprScalar.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Concepts] Requires ExpressionsSaar Raz2020-01-241-0/+4
| | | | | | | | | | Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360 (cherry picked from commit a0f50d731639350c7a79f140f026c27a18215531)
* Implement VectorType conditional operator GNU extension.Erich Keane2020-01-131-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC supports the conditional operator on VectorTypes that acts as a 'select' in C++ mode. This patch implements the support. Types are converted as closely to GCC's behavior as possible, though in a few places consistency with our existing vector type support was preferred. Note that this implementation is different from the OpenCL version in a number of ways, so it unfortunately required a different implementation. First, the SEMA rules and promotion rules are significantly different. Secondly, GCC implements COND[i] != 0 ? LHS[i] : RHS[i] (where i is in the range 0- VectorSize, for each element). In OpenCL, the condition is COND[i] < 0 ? LHS[i]: RHS[i]. In the process of implementing this, it was also required to make the expression COND ? LHS : RHS type dependent if COND is type dependent, since the type is now dependent on the condition. For example: T ? 1 : 2; Is not typically type dependent, since the result can be deduced from the operands. HOWEVER, if T is a VectorType now, it could change this to a 'select' (basically a swizzle with a non-constant mask) with the 1 and 2 being promoted to vectors themselves. While this is a change, it is NOT a standards incompatible change. Based on my (and D. Gregor's, at the time of writing the code) reading of the standard, the expression is supposed to be type dependent if ANY sub-expression is type dependent. Differential Revision: https://reviews.llvm.org/D71463
* Fix "pointer is null" static analyzer warnings. NFCI.Simon Pilgrim2020-01-111-2/+1
| | | | Use castAs<> instead of getAs<> since the pointer is dereferenced immediately below and castAs will perform the null assertion for us.
* [FPEnv] Generate constrained FP comparisons from clangUlrich Weigand2020-01-101-11/+17
| | | | | | | | | | | | | | | | | | | | | Update the IRBuilder to generate constrained FP comparisons in CreateFCmp when IsFPConstrained is true, similar to the other places in the IRBuilder. Also, add a new CreateFCmpS to emit signaling FP comparisons, and use it in clang where comparisons are supposed to be signaling (currently, only when emitting code for the <, <=, >, >= operators). Note that there is currently no way to add fast-math flags to a constrained FP comparison, since this is implemented as an intrinsic call that returns a boolean type, and FMF are only allowed for calls returning a floating-point type. However, given the discussion around https://bugs.llvm.org/show_bug.cgi?id=42179, it seems that FCmp itself really shouldn't have any FMF either, so this is probably OK. Reviewed by: craig.topper Differential Revision: https://reviews.llvm.org/D71467
* [OPENMP50]Support lastprivate conditional updates in inc/dec unary ops.Alexey Bataev2020-01-061-1/+20
| | | | | Added support for checking of updates of variables used in unary pre(pos) inc/dec expressions.
* [OPENMP50]Codegen for lastprivate conditional list items.Alexey Bataev2020-01-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Added codegen support for lastprivate conditional. According to the standard, if when the conditional modifier appears on the clause, if an assignment to a list item is encountered in the construct then the original list item is assigned the value that is assigned to the new list item in the sequentially last iteration or lexically last section in which such an assignment is encountered. We look for the assignment operations and check if the left side references lastprivate conditional variable. Then the next code is emitted: if (last_iv_a <= iv) { last_iv_a = iv; last_a = lp_a; } At the end the implicit barrier is generated to wait for the end of all threads and then in the check for the last iteration the private copy is assigned the last value. if (last_iter) { lp_a = last_a; // <--- new code a = lp_a; // <--- store of private value to the original variable. }
* [CodeGen] Use CreateFNeg in buildFMulAddCraig Topper2019-12-301-11/+4
| | | | | | We have an fneg instruction now and should use it instead of the fsub -0.0 idiom. Looks like we had no test that showed that we handled the negation cases here so I've added new tests. Differential Revision: https://reviews.llvm.org/D72010
* Reland [DataLayout] Fix occurrences that size and range of pointers are ↵Nicola Zaghen2019-12-131-2/+2
| | | | | | | | | | | | | | assumed to be the same. GEP index size can be specified in the DataLayout, introduced in D42123. However, there were still places in which getIndexSizeInBits was used interchangeably with getPointerSizeInBits. This notably caused issues with Instcombine's visitPtrToInt; but the unit tests was incorrect, so this remained undiscovered. This fixes the buildbot failures. Differential Revision: https://reviews.llvm.org/D68328 Patch by Joseph Faulls!
* Temporarily Revert "[DataLayout] Fix occurrences that size and range of ↵Nicola Zaghen2019-12-121-2/+2
| | | | | | | | | pointers are assumed to be the same." This reverts commit 5f6208778ff92567c57d7c1e2e740c284d7e69a5. This caused failures in Transforms/PhaseOrdering/scev-custom-dl.ll const: Assertion `getBitWidth() == CR.getBitWidth() && "ConstantRange types don't agree!"' failed.
* [DataLayout] Fix occurrences that size and range of pointers are assumed to ↵Nicola Zaghen2019-12-121-2/+2
| | | | | | | | | | | | be the same. GEP index size can be specified in the DataLayout, introduced in D42123. However, there were still places in which getIndexSizeInBits was used interchangeably with getPointerSizeInBits. This notably caused issues with Instcombine's visitPtrToInt; but the unit tests was incorrect, so this remained undiscovered. Differential Revision: https://reviews.llvm.org/D68328 Patch by Joseph Faulls!
* [IR] Split out target specific intrinsic enums into separate headersReid Kleckner2019-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | This has two main effects: - Optimizes debug info size by saving 221.86 MB of obj file size in a Windows optimized+debug build of 'all'. This is 3.03% of 7,332.7MB of object file size. - Incremental step towards decoupling target intrinsics. The enums are still compact, so adding and removing a single target-specific intrinsic will trigger a rebuild of all of LLVM. Assigning distinct target id spaces is potential future work. Part of PR34259 Reviewers: efriedma, echristo, MaskRay Reviewed By: echristo, MaskRay Differential Revision: https://reviews.llvm.org/D71320
* Avoid Attr.h includes, CodeGen editionReid Kleckner2019-12-091-0/+1
| | | | This saves around 20 includes of Attr.h. Not much.
* [NFC] Pass a reference to CodeGenFunction to methods of LValue andAkira Hatanaka2019-12-031-12/+13
| | | | | | | | | | | | | | AggValueSlot This reapplies 8a5b7c35709d9ce1f44a99f0c5b084bf2696ea17 after a null dereference bug in CGOpenMPRuntime::emitUserDefinedMapper. Original commit message: This is needed for the pointer authentication work we plan to do in the near future. https://github.com/apple/llvm-project/blob/a63a81bd9911f87a0b5dcd5bdd7ccdda7124af87/clang/docs/PointerAuthentication.rst
* Revert "[NFC] Pass a reference to CodeGenFunction to methods of LValue and"Akira Hatanaka2019-12-031-13/+12
| | | | | This reverts commit 8a5b7c35709d9ce1f44a99f0c5b084bf2696ea17. This seems to have broken UBSan because of a null dereference.
* [NFC] Pass a reference to CodeGenFunction to methods of LValue andAkira Hatanaka2019-12-031-12/+13
| | | | | | | | | AggValueSlot This is needed for the pointer authentication work we plan to do in the near future. https://github.com/apple/llvm-project/blob/a63a81bd9911f87a0b5dcd5bdd7ccdda7124af87/clang/docs/PointerAuthentication.rst
* [CodeGen] Fix clang crash on aggregate initialization of array of labelsJohannes Altmanninger2019-11-281-2/+2
| | | | | | | | | | | | | | | 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-271-5/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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
* Revert "[clang][CodeGen] Implicit Conversion Sanitizer: handle ↵Roman Lebedev2019-11-271-33/+3
| | | | | | | | | | increment/decrement (PR44054)" The asssertion that was added does not hold, breaks on test-suite/MultiSource/Applications/SPASS/analyze.c Will reduce the testcase and revisit. This reverts commit 9872ea4ed1de4c49300430e4f1f4dfc110a79ab9, 870f3542d3e0d06d208442bdca6482866b59171b.
* [clang][CodeGen] Implicit Conversion Sanitizer: handle increment/decrement ↵Roman Lebedev2019-11-271-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (PR44054) 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.. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44054 | PR44054 ]]. 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
* CodeGen: set correct result for atomic compound expressionsTim Northover2019-11-071-9/+20
| | | | | | | | Atomic compound expressions try to use atomicrmw if possible, but this path doesn't set the Result variable, leaving it to crash in later code if anything ever tries to use the result of the expression. This fixes that issue by recalculating the new value based on the old one atomically loaded.
* clang: Fix assert on void pointer arithmetic with address_spaceMatt Arsenault2019-10-311-1/+1
| | | | | This attempted to always use the default address space void pointer type instead of preserving the source address space.
* [c++20] Add CXXRewrittenBinaryOperator to represent a comparisonRichard Smith2019-10-191-0/+4
| | | | | | | | operator that is rewritten as a call to multiple other operators. No functionality change yet: nothing creates these expressions. llvm-svn: 375305
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-0/+4
| | | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-151-4/+0
| | | | | | | | | | This reverts commit ec87b003823d63f3342cf648f55a134c1522e612. The test fails on Windows, see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio Also revert follow-up r374893. llvm-svn: 374899
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-0/+4
| | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. llvm-svn: 374882
* [IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperatorCameron McInally2019-10-141-6/+8
| | | | | | | | Reapply r374240 with fix for Ocaml test, namely Bindings/OCaml/core.ml. Differential Revision: https://reviews.llvm.org/D61675 llvm-svn: 374782
* remove an useless allocation found by scan-build - the new Dead nested ↵Sylvestre Ledru2019-10-121-2/+2
| | | | | | assignment check llvm-svn: 374659
* Reland r374450 with Richard Smith's comments and test fixed.Erich Keane2019-10-111-2/+1
| | | | | | | | | | The behavior from the original patch has changed, since we're no longer allowing LLVM to just ignore the alignment. Instead, we're just assuming the maximum possible alignment. Differential Revision: https://reviews.llvm.org/D68824 llvm-svn: 374562
* Revert 374450 "Fix __builtin_assume_aligned with too large values."Nico Weber2019-10-101-1/+2
| | | | | | | | | | | | | The test fails on Windows, with error: 'warning' diagnostics expected but not seen: File builtin-assume-aligned.c Line 62: requested alignment must be 268435456 bytes or smaller; assumption ignored error: 'warning' diagnostics seen but not expected: File builtin-assume-aligned.c Line 62: requested alignment must be 8192 bytes or smaller; assumption ignored llvm-svn: 374456
* Fix __builtin_assume_aligned with too large values.Erich Keane2019-10-101-2/+1
| | | | | | | | | | | | | | Code to handle __builtin_assume_aligned was allowing larger values, but would convert this to unsigned along the way. This patch removes the EmitAssumeAligned overloads that take unsigned to do away with this problem. Additionally, it adds a warning that values greater than 1 <<29 are ignored by LLVM. Differential Revision: https://reviews.llvm.org/D68824 llvm-svn: 374450
* Revert "[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator"Dmitri Gribenko2019-10-101-8/+6
| | | | | | | This reverts commit r374240. It broke OCaml tests: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19014 llvm-svn: 374354
* [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined ↵Roman Lebedev2019-10-101-50/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behaviour Summary: Quote from http://eel.is/c++draft/expr.add#4: ``` 4 When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P. (4.1) If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value. (4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i−j of x if 0≤i−j≤n. (4.3) Otherwise, the behavior is undefined. ``` Therefore, as per the standard, applying non-zero offset to `nullptr` (or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined, i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.) To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer is undefined, although Clang front-end pessimizes the code by not lowering that info, so this UB is "harmless". Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`) LLVM middle-end uses those guarantees for transformations. If the source contains such UB's, said code may now be miscompiled. Such miscompilations were already observed: * https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html * https://github.com/google/filament/pull/1566 Surprisingly, UBSan does not catch those issues ... until now. This diff teaches UBSan about these UB's. `getelementpointer inbounds` is a pretty frequent instruction, so this does have a measurable impact on performance; I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%), and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark: (all measurements done with LLVM ToT, the sanitizer never fired.) * no sanitization vs. existing check: average `+21.62%` slowdown * existing check vs. check after this patch: average `22.04%` slowdown * no sanitization vs. this patch: average `48.42%` slowdown Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers Reviewed By: rsmith Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67122 llvm-svn: 374293
* [IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperatorCameron McInally2019-10-091-6/+8
| | | | | | | | Also update Clang to call Builder.CreateFNeg(...) for UnaryMinus. Differential Revision: https://reviews.llvm.org/D61675 llvm-svn: 374240
* Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.Simon Pilgrim2019-10-031-2/+2
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<RecordType> directly and if not assert will fire for us. llvm-svn: 373584
* Silence static analyzer getAs<VectorType> null dereference warnings. NFCI.Simon Pilgrim2019-10-021-3/+3
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<VectorType> directly and if not assert will fire for us. llvm-svn: 373478
* [NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): pass a vector to EmitCheck()Roman Lebedev2019-09-061-2/+6
| | | | | | | | Will be easier to add a new 'check' in a follow-up. This was originally part of https://reviews.llvm.org/D67122 llvm-svn: 371208
* [NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): refactor ↵Roman Lebedev2019-09-061-25/+52
| | | | | | | | | | | EmitGEPOffsetInBytes() helper It shouldn't really be inlined into the EmitCheckedInBoundsGEP(). Refactoring it beforehand will make follow-up changes more obvious. This was originally part of https://reviews.llvm.org/D67122 llvm-svn: 371207
* [NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): add some comments to ↵Roman Lebedev2019-09-061-8/+18
| | | | | | | | | | pointer-overflow check It's rather eye-twiching, some comments may help here.. This was originally part of https://reviews.llvm.org/D67122 llvm-svn: 371206
* Treat the range of representable values of floating-point types as [-inf, ↵Richard Smith2019-07-061-120/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +inf] not as [-max, +max]. Summary: Prior to r329065, we used [-max, max] as the range of representable values because LLVM's `fptrunc` did not guarantee defined behavior when truncating from a larger floating-point type to a smaller one. Now that has been fixed, we can make clang follow normal IEEE 754 semantics in this regard and take the larger range [-inf, +inf] as the range of representable values. In practice, this affects two parts of the frontend: * the constant evaluator no longer treats floating-point evaluations that result in +-inf as being undefined (because they no longer leave the range of representable values of the type) * UBSan no longer treats conversions to floating-point type that are outside the [-max, +max] range as being undefined In passing, also remove the float-divide-by-zero sanitizer from -fsanitize=undefined, on the basis that while it's undefined per C++ rules (and we disallow it in constant expressions for that reason), it is defined by Clang / LLVM / IEEE 754. Reviewers: rnk, BillyONeal Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63793 llvm-svn: 365272
* [C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington2019-07-021-0/+9
| | | | | | | | | | | | | | | | | | This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a bit_cast from a value v to a type T. This expression can be evaluated at compile time under specific circumstances. The compile time evaluation currently doesn't support bit-fields, but I'm planning on fixing this in a follow up (some of the logic for figuring this out is in CodeGen). I'm also planning follow-ups for supporting some more esoteric types that the constexpr evaluator supports, as well as extending __builtin_memcpy constexpr evaluation to use the same infrastructure. rdar://44987528 Differential revision: https://reviews.llvm.org/D62825 llvm-svn: 364954
* [cxx2a] P1236R1: the validity of a left shift does not depend on theRichard Smith2019-06-251-1/+2
| | | | | | value of the LHS operand. llvm-svn: 364265
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-141-2/+2
| | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r363337, reverted in r363352. llvm-svn: 363429
* Revert 363295, it caused PR42276. Also revert follow-ups 363337, 363340.Nico Weber2019-06-141-2/+2
| | | | | | | | Revert 363340 "Remove unused SK_LValueToRValue initialization step." Revert 363337 "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type" Revert 363295 "C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression." llvm-svn: 363352
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-131-2/+2
| | | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r345562, reverted in r346065, now that CodeGen's handling of non-odr-used variables has been fixed. llvm-svn: 363337
* ScalarExprEmitter::EmitCompoundAssign - fix uninitialized variable warning. ↵Simon Pilgrim2019-05-181-1/+1
| | | | | | NFCI. llvm-svn: 361098
* Implement __builtin_LINE() et. al. to support source location capture.Eric Fiselier2019-05-161-1/+10
| | | | | | | | | | | | | | | | | Summary: This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation). With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong Reviewed By: rsmith Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D37035 llvm-svn: 360937
* Change the metadata for heapallocsite calls when the type is cast.Amy Huang2019-05-021-0/+6
| | | | llvm-svn: 359823
* [Fixed Point Arithmetic] Fixed Point and Integer ConversionsLeonard Chan2019-03-061-21/+54
| | | | | | | | | This patch includes the necessary code for converting between a fixed point type and integer. This also includes constant expression evaluation for conversions with these types. Differential Revision: https://reviews.llvm.org/D56900 llvm-svn: 355462
* [CodeGen] Fix some broken IR generated by -fsanitize=unsigned-integer-overflowErik Pilkington2019-02-281-6/+6
| | | | | | | | | | | | | | I think the author of the function assumed that `GetInsertBlock()` wouldn't change from where `atomicPHI` was created, but this isn't true when `-fsanitize=unsigned-integer-overflow` is enabled (we generate an overflow/continuation label). Fix by keeping track of the block we want to return to to complete the cmpxchg loop. rdar://48406558 Differential revision: https://reviews.llvm.org/D58744 llvm-svn: 355054
* [Fixed Point Arithmetic] Fixed Point ComparisonsLeonard Chan2019-02-211-12/+34
| | | | | | | | | This patch implements fixed point comparisons with other fixed point types and integers. This also provides constant expression evaluation for them. Differential Revision: https://reviews.llvm.org/D57219 llvm-svn: 354621
OpenPOWER on IntegriCloud