summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGBuiltin.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [opaque pointer types] Pass function types for runtime function calls.James Y Knight2019-02-051-6/+7
| | | | | | | | | | | | | Emit{Nounwind,}RuntimeCall{,OrInvoke} have been modified to take a FunctionCallee as an argument, and CreateRuntimeFunction has been modified to return a FunctionCallee. All callers have been updated. Additionally, CreateBuiltinFunction is removed, as it was redundant with CreateRuntimeFunction after some previous changes. Differential Revision: https://reviews.llvm.org/D57668 llvm-svn: 353184
* [opaque pointer types] Trivial changes towards CallInst requiringJames Y Knight2019-02-031-89/+92
| | | | | | explicit function types. llvm-svn: 353009
* Add a new builtin: __builtin_dynamic_object_sizeErik Pilkington2019-01-301-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | This builtin has the same UI as __builtin_object_size, but has the potential to be evaluated dynamically. It is meant to be used as a drop-in replacement for libraries that use __builtin_object_size when a dynamic checking mode is enabled. For instance, __builtin_object_size fails to provide any extra checking in the following function: void f(size_t alloc) { char* p = malloc(alloc); strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0)) } This is an overflow if alloc < 7, but because LLVM can't fold the object size intrinsic statically, it folds __builtin_object_size to -1. With __builtin_dynamic_object_size, alloc is passed through to __builtin___strcpy_chk. rdar://32212419 Differential revision: https://reviews.llvm.org/D56760 llvm-svn: 352665
* Add a 'dynamic' parameter to the objectsize intrinsicErik Pilkington2019-01-301-1/+2
| | | | | | | | | | | | | | This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
* Cleanup: replace uses of CallSite with CallBase.James Y Knight2019-01-301-10/+9
| | | | llvm-svn: 352595
* AMDGPU: Add ds append/consume builtinsMatt Arsenault2019-01-281-0/+8
| | | | llvm-svn: 352443
* [X86] Add new variadic avx512 compress/expand intrinsics that use vXi1 types ↵Craig Topper2019-01-281-0/+54
| | | | | | | | for the mask argument. Custom lower the builtins to these intrinsics. This enables the middle end to optimize out bitcasts for the masks. llvm-svn: 352344
* [X86] Custom codegen 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops ↵Craig Topper2019-01-261-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | intrinsics. Summary: The 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics all have the possibility of taking an explicit rounding mode argument. If the rounding mode is CUR_DIRECTION we'd like to emit a sitofp/uitofp instruction and a select like we do for 256-bit intrinsics. For cvt(u)qqtopd and cvt(u)dqtops we do this when the form of the software intrinsics that doesn't take a rounding mode argument is used. This is done by using convertvector in the header with the select builtin. But if the explicit rounding mode form of the intrinsic is used and CUR_DIRECTION is passed, we don't do this. We shouldn't have this inconsistency. For cvt(u)qqtops nothing is done because we can't use the select builtin in the header without avx512vl. So we need to use custom codegen for this. Even when the rounding mode isn't CUR_DIRECTION we should also use select in IR for consistency. And it will remove another scalar integer mask from our intrinsics. To accomplish all of these goals I've taken a slightly unusual approach. I've added two new X86 specific intrinsics for sitofp/uitofp with rounding. These intrinsics are variadic on the input and output type so we only need 2 instead of 6. This avoids the need for a switch to map them in CGBuiltin.cpp. We just need to check signed vs unsigned. I believe other targets also use variadic intrinsics like this. So if the rounding mode is CUR_DIRECTION we'll use an sitofp/uitofp instruction. Otherwise we'll use one of the new intrinsics. After that we'll emit a select instruction if needed. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D56998 llvm-svn: 352267
* [X86] Replace VPCOM/VPCOMU with generic integer comparisons (clang)Simon Pilgrim2019-01-201-0/+50
| | | | | | | | | | These intrinsics can always be replaced with generic integer comparisons without any regression in codegen, even for -O0/-fast-isel cases. Noticed while cleaning up vector integer comparison costs for PR40376. A future commit will remove/autoupgrade the existing VPCOM/VPCOMU llvm intrinsics. llvm-svn: 351687
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* CodeGen: Cast llvm.flt.rounds result to match __builtin_flt_roundsAnton Korobeynikov2019-01-171-0/+11
| | | | | | | | | | | | | llvm.flt.rounds returns an i32, but the builtin expects an integer. On targets where integers are not 32-bits clang tries to bitcast the result, causing an assertion failure. The patch enables newlib build for msp430. Patch by Edward Jones! Differential Revision: https://reviews.llvm.org/D24461 llvm-svn: 351449
* [X86] Add custom emission for the avx512 scatter builtins to convert from ↵Craig Topper2019-01-171-0/+108
| | | | | | scalar integer to vXi1 for the mask arguments to the intrinsics. llvm-svn: 351408
* Recommit r351160 "[X86] Make _xgetbv/_xsetbv on non-windows platforms"Craig Topper2019-01-161-1/+10
| | | | | | V8 has been fixed now. llvm-svn: 351391
* [X86] Add versions of the avx512 gather intrinsics that take the mask as a ↵Craig Topper2019-01-161-0/+108
| | | | | | | | | | vXi1 vector instead of a scalar We need to custom handle these so we can turn the scalar mask into a vXi1 vector. Differential Revision: https://reviews.llvm.org/D56530 llvm-svn: 351390
* Revert "[X86] Make _xgetbv/_xsetbv on non-windows platforms"Benjamin Kramer2019-01-151-10/+1
| | | | | | This reverts commit r351160. Breaks building v8. llvm-svn: 351210
* [clang][UBSan] Sanitization for alignment assumptions.Roman Lebedev2019-01-151-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: UB isn't nice. It's cool and powerful, but not nice. Having a way to detect it is nice though. [[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says: ``` We propose to add this functionality via a library function instead of a core language attribute. ... If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour. ``` This differential teaches clang to sanitize all the various variants of this assume-aligned attribute. Requires D54588 for LLVM IRBuilder changes. The compiler-rt part is D54590. This is a second commit, the original one was r351105, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall Reviewed By: rjmccall Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54589 llvm-svn: 351177
* [X86] Make _xgetbv/_xsetbv on non-windows platformsCraig Topper2019-01-151-1/+10
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch attempts to redo what was tried in r278783, but was reverted. These intrinsics should be available on non-windows platforms with "xsave" feature check. But on Windows platforms they shouldn't have feature check since that's how MSVC behaves. To accomplish this I've added a MS builtin with no feature check. And a normal gcc builtin with a feature check. When _MSC_VER is not defined _xgetbv/_xsetbv will be macros pointing to the gcc builtin name. I've moved the forward declarations from intrin.h to immintrin.h to match the MSDN documentation and used that as the header file for the MS builtin. I'm not super happy with this implementation, and I'm open to suggestions for better ways to do it. Reviewers: rnk, RKSimon, spatel Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D56686 llvm-svn: 351160
* Revert alignment assumptions changesVlad Tsyrklevich2019-01-151-5/+3
| | | | | | | Revert r351104-6, r351109, r351110, r351119, r351134, and r351153. These changes fail on the sanitizer bots. llvm-svn: 351159
* [clang][UBSan] Sanitization for alignment assumptions.Roman Lebedev2019-01-141-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: UB isn't nice. It's cool and powerful, but not nice. Having a way to detect it is nice though. [[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says: ``` We propose to add this functionality via a library function instead of a core language attribute. ... If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour. ``` This differential teaches clang to sanitize all the various variants of this assume-aligned attribute. Requires D54588 for LLVM IRBuilder changes. The compiler-rt part is D54590. Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall Reviewed By: rjmccall Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54589 llvm-svn: 351105
* [WebAssembly] Remove old builtinsDan Gohman2019-01-141-25/+0
| | | | | | | | | This removes the old grow_memory and mem.grow-style builtins, leaving just the memory.grow-style builtins. Differential Revision: https://reviews.llvm.org/D56645 llvm-svn: 351089
* [X86] Remove mask parameter from avx512 pmultishiftqb intrinsics. Use select ↵Craig Topper2019-01-141-2/+22
| | | | | | | | in IR instead. Fixes PR40259 llvm-svn: 351036
* [X86] Remove mask parameter from vpshufbitqmb intrinsics. Change result to a ↵Craig Topper2019-01-141-0/+25
| | | | | | | | | | vXi1 vector. We'll do the scalar<->vXi1 conversions with bitcasts in IR. Fixes PR40258 llvm-svn: 351029
* Recommit r350555 "[X86] Use funnel shift intrinsics for the VBMI2 ↵Craig Topper2019-01-071-0/+46
| | | | | | | | vshld/vshrd builtins." The MSVC limit hit in AutoUpgrade.cpp has been worked around for now. llvm-svn: 350568
* Revert r350555 "[X86] Use funnel shift intrinsics for the VBMI2 vshld/vshrd ↵Craig Topper2019-01-071-46/+0
| | | | | | | | builtins." Had to revert the LLVM patch this depends on to fix a MSVC compiler limit in AutoUpgrade.cpp llvm-svn: 350563
* [X86] Use funnel shift intrinsics for the VBMI2 vshld/vshrd builtins.Craig Topper2019-01-071-0/+46
| | | | | | Differential Revision: https://reviews.llvm.org/D56365 llvm-svn: 350555
* Declares __cpu_model as dso localHaibo Huang2018-12-201-0/+7
| | | | | | | | __builtin_cpu_supports and __builtin_cpu_is use information in __cpu_model to decide cpu features. Before this change, __cpu_model was not declared as dso local. The generated code looks up the address in GOT when reading __cpu_model. This makes it impossible to use these functions in ifunc, because at that time GOT entries have not been relocated. This change makes it dso local. Differential Revision: https://reviews.llvm.org/D53850 llvm-svn: 349825
* [X86] Auto upgrade XOP/AVX512 rotation intrinsics to generic funnel shift ↵Simon Pilgrim2018-12-201-1/+53
| | | | | | | | | | | | intrinsics (clang) This emits FSHL/FSHR generic intrinsics for the XOP VPROT and AVX512 VPROL/VPROR rotation intrinsics. LLVM counterpart: https://reviews.llvm.org/D55938 Differential Revision: https://reviews.llvm.org/D55937 llvm-svn: 349796
* [X86][SSE] Auto upgrade PADDS/PSUBS intrinsics to SADD_SAT/SSUB_SAT generic ↵Simon Pilgrim2018-12-201-6/+21
| | | | | | | | | | | | intrinsics (clang) This emits SADD_SAT/SSUB_SAT generic intrinsics for the SSE signed saturated math intrinsics. LLVM counterpart: https://reviews.llvm.org/D55894 Differential Revision: https://reviews.llvm.org/D55890 llvm-svn: 349743
* [X86][SSE] Auto upgrade PADDUS/PSUBUS intrinsics to UADD_SAT/USUB_SAT ↵Simon Pilgrim2018-12-191-25/+8
| | | | | | | | | | generic intrinsics (clang) Sibling patch to D55855, this emits UADD_SAT/USUB_SAT generic intrinsics for the SSE saturated math intrinsics instead of expanding to a IR code sequence that could be difficult to reassemble. Differential Revision: https://reviews.llvm.org/D55879 llvm-svn: 349631
* [CodeGen] Handle mixed-width ops in mixed-sign mul-with-overflow loweringVedant Kumar2018-12-181-5/+14
| | | | | | | | | | | | | | | | | | | | | | The special lowering for __builtin_mul_overflow introduced in r320902 fixed an ICE seen when passing mixed-sign operands to the builtin. This patch extends the special lowering to cover mixed-width, mixed-sign operands. In a few common scenarios, calls to muloti4 will no longer be emitted. This should address the latest comments in PR34920 and work around the link failure seen in: https://bugzilla.redhat.com/show_bug.cgi?id=1657544 Testing: - check-clang - A/B output comparison with: https://gist.github.com/vedantk/3eb9c88f82e5c32f2e590555b4af5081 Differential Revision: https://reviews.llvm.org/D55843 llvm-svn: 349542
* [Clang] Add __builtin_launderEric Fiselier2018-12-141-0/+46
| | | | | | | | | | | | | | | | | Summary: This patch adds `__builtin_launder`, which is required to implement `std::launder`. Additionally GCC provides `__builtin_launder`, so thing brings Clang in-line with GCC. I'm not exactly sure what magic `__builtin_launder` requires, but based on previous discussions this patch applies a `@llvm.invariant.group.barrier`. As noted in previous discussions, this may not be enough to correctly handle vtables. Reviewers: rnk, majnemer, rsmith Reviewed By: rsmith Subscribers: kristina, Romain-Geissler-1A, erichkeane, amharc, jroelofs, cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D40218 llvm-svn: 349195
* [Builltins][X86] Provide implementations of __lzcnt16, __lzcnt, __lzcnt64 ↵Craig Topper2018-12-141-0/+15
| | | | | | | | | | | | | | | | | | for MS compatibility. Remove declarations from intrin.h and implementations from lzcntintrin.h intrin.h had forward declarations for these and lzcntintrin.h had implementations that were only available with -mlzcnt or a -march that supported the lzcnt feature. For MS compatibility we should always have these builtins available regardless of X86 being the target or the CPU support the lzcnt instruction. The backends should be able to gracefully fallback to something support even if its just shifts and bit ops. Unfortunately, gcc also implements 2 of the 3 function names here on X86 when lzcnt feature is enabled. This patch adds builtins for these for MSVC compatibility and drops the forward declarations from intrin.h. To keep the gcc compatibility the two intrinsics that collided have been turned into macros that use the X86 specific builtins with the lzcnt feature check. These macros are only defined when _MSC_VER is not defined. Without them being macros we can get a redefinition error because -ms-extensions doesn't seem to set _MSC_VER but does make the MS builtins available. Should fix PR40014 Differential Revision: https://reviews.llvm.org/D55677 llvm-svn: 349098
* Revert "Declares __cpu_model as dso local"Haibo Huang2018-12-121-5/+0
| | | | | | This reverts r348978 llvm-svn: 348982
* Declares __cpu_model as dso localHaibo Huang2018-12-121-0/+5
| | | | | | | | __builtin_cpu_supports and __builtin_cpu_is use information in __cpu_model to decide cpu features. Before this change, __cpu_model was not declared as dso local. The generated code looks up the address in GOT when reading __cpu_model. This makes it impossible to use these functions in ifunc, because at that time GOT entries have not been relocated. This change makes it dso local. Differential Revision: https://reviews.llvm.org/D53850 llvm-svn: 348978
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-101-6/+6
| | | | | | | | | | | | | | Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned` Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D55475 llvm-svn: 348755
* [X86] Remove the addcarry builtins. Leaving only the addcarryx builtins ↵Craig Topper2018-12-101-12/+4
| | | | | | | | | | since that matches gcc. The addcarry and addcarryx builtins do the same thing. The only difference is that addcarryx previously required adx feature. This commit removes the adx feature check from addcarryx and removes the addcarry builtin. This matches the builtins that gcc has. We don't guarantee compatibility in builtins, but we generally try to be consistent if its not a burden. llvm-svn: 348738
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-13/+41
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-41/+13
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-13/+41
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-41/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* [CodeGen] translate MS rotate builtins to LLVM funnel-shift intrinsicsSanjay Patel2018-11-251-40/+10
| | | | | | | | | | | | | | This was originally part of: D50924 and should resolve PR37387: https://bugs.llvm.org/show_bug.cgi?id=37387 ...but it was reverted because some bots using a gcc host compiler would crash for unknown reasons with this included in the patch. Trying again now to see if that's still a problem. llvm-svn: 347527
* A __builtin_constant_p() returns 0 with a function type.Bill Wendling2018-11-221-1/+1
| | | | llvm-svn: 347480
* The result of is.constant() is unsigned.Bill Wendling2018-11-221-1/+1
| | | | llvm-svn: 347446
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-13/+41
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-41/+13
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-13/+41
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Revert 347294, it turned many bots on lab.llvm.org:8011/console red.Nico Weber2018-11-201-20/+0
| | | | llvm-svn: 347314
* Use is.constant intrinsic for __builtin_constant_pBill Wendling2018-11-201-0/+20
| | | | | | | | | | | | | | | | Summary: A __builtin_constant_p may end up with a constant after inlining. Use the is.constant intrinsic if it's a variable that's in a context where it may resolve to a constant, e.g., an argument to a function after inlining. Reviewers: rsmith, shafik Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight Differential Revision: https://reviews.llvm.org/D54355 llvm-svn: 347294
* [OpenCL] Fix invalid address space generation for clk_event_tAlexey Sotkin2018-11-141-1/+3
| | | | | | | | | | | | | | | | | | Summary: Addrspace(32) was generated when putting 0 in clk_event_t * event_ret parameter for enqueue_kernel function. Patch by Viktoria Maksimova Reviewers: Anastasia, yaxunl, AlexeySotkin Reviewed By: Anastasia, AlexeySotkin Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D53809 llvm-svn: 346838
* [NFC] Move storage of dispatch-version to GlobalDeclErich Keane2018-11-131-4/+5
| | | | | | | | | | | | | | | | | | | As suggested by Richard Smith, and initially put up for review here: https://reviews.llvm.org/D53341, this patch removes a hack that was used to ensure that proper target-feature lists were used when emitting cpu-dispatch (and eventually, target-clones) implementations. As a part of this, the GlobalDecl object is proliferated to a bunch more locations. Originally, this was put up for review (see above) to get acceptance on the approach, though discussion with Richard in San Diego showed he approved of the approach taken here. Thus, I believe this is acceptable for Review-After-commit Differential Revision: https://reviews.llvm.org/D53341 Change-Id: I0a0bd673340d334d93feac789d653e03d9f6b1d5 llvm-svn: 346757
OpenPOWER on IntegriCloud