summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-313-14/+14
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-313-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* [CallSite removal] Remove CallSite uses from InstCombine.Craig Topper2019-01-311-0/+15
| | | | | | | | | | | | Reviewers: chandlerc Reviewed By: chandlerc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D57494 llvm-svn: 352771
* Add a 'dynamic' parameter to the objectsize intrinsicErik Pilkington2019-01-301-1/+3
| | | | | | | | | | | | | | 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
* Remove a redundant space from an error message; NFCGeorge Burgess IV2019-01-301-1/+1
| | | | llvm-svn: 352576
* [IR] Use CallBase to reduce code duplication. NFCCraig Topper2019-01-291-4/+2
| | | | | | | | Noticed in the asm-goto patch. Callbr needs to go here too. One cast and call is better than 3. Differential Revision: https://reviews.llvm.org/D57295 llvm-svn: 352563
* [X86] Add new variadic avx512 compress/expand intrinsics that use vXi1 types ↵Craig Topper2019-01-281-0/+23
| | | | | | | | for the mask argument. Remove and autoupgrade the old intrinsics llvm-svn: 352343
* [X86] Remove and autoupgrade vpconflict intrinsics that take a mask and ↵Craig Topper2019-01-261-0/+16
| | | | | | | | passthru argument. We have unmasked versions as of r352172 llvm-svn: 352270
* [X86] Remove GCCBuiltins from 512-bit cvt(u)qqtops, cvt(u)qqtopd, and ↵Craig Topper2019-01-261-23/+32
| | | | | | | | | | | | | | | | cvt(u)dqtops intrinsics. Add new variadic uitofp/sitofp with rounding mode intrinsics. Summary: See clang patch D56998 for a full description. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56999 llvm-svn: 352266
* [DiagnosticInfo] Add support for preserving newlines in remark arguments.Florian Hahn2019-01-251-1/+23
| | | | | | | | | | | | | | | | | | | | This patch adds a new type StringBlockVal which can be used to emit a YAML block scalar, which preserves newlines in a multiline string. It also updates MappingTraits<DiagnosticInfoOptimizationBase::Argument> to use it for argument values with more than a single newline. This is helpful for remarks that want to display more in-depth information in a more structured way. Reviewers: thegameg, anemet Reviewed By: anemet Subscribers: hfinkel, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D57159 llvm-svn: 352216
* Revert "[Sanitizers] UBSan unreachable incompatible with ASan in the ↵Julian Lettner2019-01-242-3/+0
| | | | | | | | presence of `noreturn` calls" This reverts commit cea84ab93aeb079a358ab1c8aeba6d9140ef8b47. llvm-svn: 352069
* [Sanitizers] UBSan unreachable incompatible with ASan in the presence of ↵Julian Lettner2019-01-242-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `noreturn` calls Summary: UBSan wants to detect when unreachable code is actually reached, so it adds instrumentation before every `unreachable` instruction. However, the optimizer will remove code after calls to functions marked with `noreturn`. To avoid this UBSan removes `noreturn` from both the call instruction as well as from the function itself. Unfortunately, ASan relies on this annotation to unpoison the stack by inserting calls to `_asan_handle_no_return` before `noreturn` functions. This is important for functions that do not return but access the the stack memory, e.g., unwinder functions *like* `longjmp` (`longjmp` itself is actually "double-proofed" via its interceptor). The result is that when ASan and UBSan are combined, the `noreturn` attributes are missing and ASan cannot unpoison the stack, so it has false positives when stack unwinding is used. Changes: # UBSan now adds the `expect_noreturn` attribute whenever it removes the `noreturn` attribute from a function # ASan additionally checks for the presence of this attribute Generated code: ``` call void @__asan_handle_no_return // Additionally inserted to avoid false positives call void @longjmp call void @__asan_handle_no_return call void @__ubsan_handle_builtin_unreachable unreachable ``` The second call to `__asan_handle_no_return` is redundant. This will be cleaned up in a follow-up patch. rdar://problem/40723397 Reviewers: delcypher, eugenis Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D56624 llvm-svn: 352003
* [ADT] Notify ilist traits about in-list transfersReid Kleckner2019-01-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously no client of ilist traits has needed to know about transfers of nodes within the same list, so as an optimization, ilist doesn't call transferNodesFromList in that case. However, now there are clients that want to use ilist traits to cache instruction ordering information to optimize dominance queries of instructions in the same basic block. This change updates the existing ilist traits users to detect in-list transfers and do nothing in that case. After this change, we can start caching instruction ordering information in LLVM IR data structures. There are two main ways to do that: - by putting an order integer into the Instruction class - by maintaining order integers in a hash table on BasicBlock I plan to implement and measure both, but I wanted to commit this change first to enable other out of tree ilist clients to implement this optimization as well. Reviewers: lattner, hfinkel, chandlerc Subscribers: hiraditya, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D57120 llvm-svn: 351992
* Fix indentation. NFCI.Simon Pilgrim2019-01-231-13/+13
| | | | llvm-svn: 351958
* [IR] Match intrinsic parameter by scalar/vectorwidthSimon Pilgrim2019-01-231-11/+14
| | | | | | | | | | | | | | This patch replaces the existing LLVMVectorSameWidth matcher with LLVMScalarOrSameVectorWidth. The matching args must be either scalars or vectors with the same number of elements, but in either case the scalar/element type can differ, specified by LLVMScalarOrSameVectorWidth. I've updated the _overflow intrinsics to demonstrate this - allowing it to return a i1 or <N x i1> overflow result, matching the scalar/vectorwidth of the other (add/sub/mul) result type. The masked load/store/gather/scatter intrinsics have also been updated to use this, although as we specify the reference type to be llvm_anyvector_ty we guarantee the mask will be <N x i1> so no change in behaviour Differential Revision: https://reviews.llvm.org/D57090 llvm-svn: 351957
* Reapply "IR: Add fp operations to atomicrmw"Matt Arsenault2019-01-222-0/+9
| | | | | | | This reapplies commits r351778 and r351782 with RISCV test fixes. llvm-svn: 351850
* Revert r351778: IR: Add fp operations to atomicrmwChandler Carruth2019-01-222-9/+0
| | | | | | | | | | | | | This broke the RISCV build, and even with that fixed, one of the RISCV tests behaves surprisingly differently with asserts than without, leaving there no clear test pattern to use. Generally it seems bad for hte IR to differ substantially due to asserts (as in, an alloca is used with asserts that isn't needed without!) and nothing I did simply would fix it so I'm reverting back to green. This also required reverting the RISCV build fix in r351782. llvm-svn: 351796
* IR: Add fp operations to atomicrmwMatt Arsenault2019-01-222-0/+9
| | | | | | Add just fadd/fsub for now. llvm-svn: 351778
* [X86] Remove and autoupgrade vpmovqd/vpmovwb intrinsics using trunc+select.Craig Topper2019-01-211-0/+12
| | | | llvm-svn: 351729
* [X86] Auto upgrade VPCOM/VPCOMU intrinsics to generic integer comparisonsSimon Pilgrim2019-01-201-21/+25
| | | | | | | | This causes a couple of changes in the upgrade tests as signed/unsigned eq/ne are equivalent and we constant fold true/false codes, these changes are the same as what we already do for avx512 cmp/ucmp. Noticed while cleaning up vector integer comparison costs for PR40376. llvm-svn: 351697
* [X86] Auto upgrade old style VPCOM/VPCOMU intrinsics to generic integer ↵Simon Pilgrim2019-01-201-22/+47
| | | | | | | | | | | | comparisons We were upgrading these to the new style VPCOM/VPCOMU intrinsics (which includes the condition code immediate), but we'll be getting rid of those shortly, so convert these to generics first. This causes a couple of changes in the upgrade tests as signed/unsigned eq/ne are equivalent and we constant fold true/false codes, these changes are the same as what we already do for avx512 cmp/ucmp. Noticed while cleaning up vector integer comparison costs for PR40376. llvm-svn: 351690
* [NFC] Fix unused variable warnings in Release buildsJohannes Doerfert2019-01-191-0/+2
| | | | llvm-svn: 351641
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1961-244/+183
| | | | | | | | | | | | | | | | | 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
* AbstractCallSite -- A unified interface for (in)direct and callback callsJohannes Doerfert2019-01-194-0/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An abstract call site is a wrapper that allows to treat direct, indirect, and callback calls the same. If an abstract call site represents a direct or indirect call site it behaves like a stripped down version of a normal call site object. The abstract call site can also represent a callback call, thus the fact that the initially called function (=broker) may invoke a third one (=callback callee). In this case, the abstract call side hides the middle man, hence the broker function. The result is a representation of the callback call, inside the broker, but in the context of the original instruction that invoked the broker. Again, there are up to three functions involved when we talk about callback call sites. The caller (1), which invokes the broker function. The broker function (2), that may or may not invoke the callback callee. And finally the callback callee (3), which is the target of the callback call. The abstract call site will handle the mapping from parameters to arguments depending on the semantic of the broker function. However, it is important to note that the mapping is often partial. Thus, some arguments of the call/invoke instruction are mapped to parameters of the callee while others are not. At the same time, arguments of the callback callee might be unknown, thus "null" if queried. This patch introduces also !callback metadata which describe how a callback broker maps from parameters to arguments. This metadata is directly created by clang for known broker functions, provided through source code attributes by the user, or later deduced by analyses. For motivation and additional information please see the corresponding talk (slides/video) https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk20 as well as the LCPC paper http://compilers.cs.uni-saarland.de/people/doerfert/par_opt_lcpc18.pdf Differential Revision: https://reviews.llvm.org/D54498 llvm-svn: 351627
* Revert "[ThinLTO] Add summary entries for index-based WPD"Teresa Johnson2019-01-171-38/+0
| | | | | | | | Mistaken commit of something still under review! This reverts commit r351453. llvm-svn: 351455
* [ThinLTO] Add summary entries for index-based WPDTeresa Johnson2019-01-171-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If LTOUnit splitting is disabled, the module summary analysis computes the summary information necessary to perform single implementation devirtualization during the thin link with the index and no IR. The information collected from the regular LTO IR in the current hybrid WPD algorithm is summarized, including: 1) For vtable definitions, record the function pointers and their offset within the vtable initializer (subsumes the information collected from IR by tryFindVirtualCallTargets). 2) A record for each type metadata summarizing the vtable definitions decorated with that metadata (subsumes the TypeIdentiferMap collected from IR). Also added are the necessary bitcode records, and the corresponding assembly support. The index-based WPD will be sent as a follow-on. Depends on D53890. Reviewers: pcc Subscribers: mehdi_amini, Prazek, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54815 llvm-svn: 351453
* Allow FP types for atomicrmw xchgMatt Arsenault2019-01-171-4/+11
| | | | llvm-svn: 351427
* [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfpMandeep Singh Grang2019-01-161-0/+4
| | | | | | | | | | | | | | | | Summary: Make recoverfp intrinsic target-independent so that it can be implemented for AArch64, etc. Refer D53541 for the context. Clang counterpart D56748. Reviewers: rnk, efriedma Reviewed By: rnk, efriedma Subscribers: javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D56747 llvm-svn: 351281
* [opaque pointer types] Update GetElementPtr creation APIs toJames Y Knight2019-01-141-7/+41
| | | | | | | | | | consistently accept a pointee-type argument. Note: this also adds a new C API and soft-deprecates the old C API. Differential Revision: https://reviews.llvm.org/D56559 llvm-svn: 351124
* [opaque pointer types] Update LoadInst creation APIs to consistentlyJames Y Knight2019-01-142-57/+24
| | | | | | | | | | accept a return-type argument. Note: this also adds a new C API and soft-deprecates the old C API. Differential Revision: https://reviews.llvm.org/D56558 llvm-svn: 351123
* [opaque pointer types] Update InvokeInst creation APIs to consistentlyJames Y Knight2019-01-141-3/+16
| | | | | | | | | | accept a callee-type argument. Note: this also adds a new C API and soft-deprecates the old C API. Differential Revision: https://reviews.llvm.org/D56557 llvm-svn: 351122
* [opaque pointer types] Update CallInst creation APIs to consistentlyJames Y Knight2019-01-142-20/+30
| | | | | | | | | | accept a callee-type argument. Note: this also adds a new C API and soft-deprecates the old C API. Differential Revision: https://reviews.llvm.org/D56556 llvm-svn: 351121
* Remove NameLen argument from newly-introduced IR C APIs.James Y Knight2019-01-141-6/+5
| | | | | | | | | | | | | | | | | | | | | Normally, changing the function signatures of C APIs is disallowed, but as these two are brand new last week, and haven't been released yet, it is okay in this instance. As per discussion in D56556, we will not add NameLen arguments to IR building APIs, for the following reasons: 1. We do not want to deprecate all of the IR building APIs, just to add a NameLen argument to each one. 2. Consistency is important, so adding it just to new ones is unfortunate. 3. The IR names are completely optional, useful for readability of IR only. There is no value in ever supporting nul bytes. Differential Revision: https://reviews.llvm.org/D56669 llvm-svn: 351076
* [X86] Remove mask parameter from avx512 pmultishiftqb intrinsics. Use select ↵Craig Topper2019-01-141-0/+10
| | | | | | | | in IR instead. Fixes PR40259 llvm-svn: 351035
* [X86] Remove mask parameter from vpshufbitqmb intrinsics. Change result to a ↵Craig Topper2019-01-141-0/+15
| | | | | | | | | | vXi1 vector. The input mask can be represented with an AND in IR. Fixes PR40258 llvm-svn: 351028
* [opaque pointer types] Remove some calls to generic Type subtype accessors.James Y Knight2019-01-102-4/+3
| | | | | | | | | | | | That is, remove many of the calls to Type::getNumContainedTypes(), Type::subtypes(), and Type::getContainedType(N). I'm not intending to remove these accessors -- they are useful/necessary in some cases. However, removing the pointee type from pointers would potentially break some uses, and reducing the number of calls makes it easier to audit. llvm-svn: 350835
* Rename DIFlagFixedEnum to DIFlagEnumClass. NFCPaul Robinson2019-01-081-2/+2
| | | | llvm-svn: 350641
* [LLVM-C] Allow For Creating a BasicBlock without a Parent FunctionRobert Widmann2019-01-081-0/+6
| | | | | | | | | | | | | | Summary: Add a utility function for creating a basic block without a parent function. A useful operation for compilers that need to synthesize and conditionally insert code without having to bother with appending and immediately unlinking a block. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56279 llvm-svn: 350608
* [LLVM-C] Allow Specifying Signedness in Int CastRobert Widmann2019-01-081-0/+7
| | | | | | | | | | | | | | Summary: Fix an old outstanding problem with the int cast builder binding always assuming the cast is signed by introducing a new LLVMBuildIntCast2 operation and deprecating the old prototype. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56280 llvm-svn: 350607
* [Verifier] Reject invalid type for DILocalVariable.Davide Italiano2019-01-071-0/+2
| | | | | | | | | | Reviewers: aprantl Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D56414 llvm-svn: 350578
* Recommit r350554 "[X86] Remove AVX512VBMI2 concat and shift intrinsics. ↵Craig Topper2019-01-071-42/+50
| | | | | | | | Replace with target independent funnel shift intrinsics." The MSVC limit we hit on AutoUpgrade.cpp has been worked around for now. llvm-svn: 350567
* [X86][AutoUpgrade] Make some tweaks to reduce the number of nested if/else ↵Craig Topper2019-01-071-96/+79
| | | | | | | | | | | | in the intrinsic upgrade code to avoid an MSVC compiler limit. MSVC has a nesting limit of around 110-130. An if/else if/else if counts against this next level. The autoupgrade code consists a long chain of these checking matches against strings. This commit moves some code to a helper function to move out a large if/else chain that was inside of one of the blocks into a separate function. There are more of these we could move or we could change some to lookup tables. I've also merged together a few similar blocks in the outer chain. This should buy us some margin for a little bit. llvm-svn: 350564
* Revert r350554 "[X86] Remove AVX512VBMI2 concat and shift intrinsics. ↵Craig Topper2019-01-071-50/+42
| | | | | | | | Replace with target independent funnel shift intrinsics." The AutoUpgrade.cpp if/else cascade hit an MSVC limit again. llvm-svn: 350562
* [X86] Remove AVX512VBMI2 concat and shift intrinsics. Replace with target ↵Craig Topper2019-01-071-42/+50
| | | | | | | | independent funnel shift intrinsics. Differential Revision: https://reviews.llvm.org/D56377 llvm-svn: 350554
* [CallSite removal] Move the rest of IR implementation code away fromChandler Carruth2019-01-074-51/+44
| | | | | | | | | | | | | | `CallSite`. With this change, the remaining `CallSite` usages are just for implementing the wrapper type itself. This does update the C API but leaves the names of that API alone and only updates their implementation. Differential Revision: https://reviews.llvm.org/D56184 llvm-svn: 350509
* [CallSite removal] Port `IndirectCallSiteVisitor` to use `CallBase` andChandler Carruth2019-01-071-0/+10
| | | | | | | | | | | update client code. Also rename it to use the more generic term `call` instead of something that could be confused with a praticular type. Differential Revision: https://reviews.llvm.org/D56183 llvm-svn: 350508
* [CallSite removal] Move the verifier to use `CallBase` instead of theChandler Carruth2019-01-071-284/+284
| | | | | | | | | | | `CallSite` wrapper. Mostly mechanical, but I've tried to tidy up code where it made sense to do so. Differential Revision: https://reviews.llvm.org/D56143 llvm-svn: 350507
* Revert patches 348835 and 348571 because they'reRanjeet Singh2019-01-041-5/+4
| | | | | | causing code size performance regressions. llvm-svn: 350402
* [BasicAA] Support arbitrary pointer sizes (and fix an overflow bug)Hal Finkel2019-01-021-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Motivated by the discussion in D38499, this patch updates BasicAA to support arbitrary pointer sizes by switching most remaining non-APInt calculations to use APInt. The size of these APInts is set to the maximum pointer size (maximum over all address spaces described by the data layout string). Most of this translation is straightforward, but this patch contains a fix for a bug that revealed itself during this translation process. In order for test/Analysis/BasicAA/gep-and-alias.ll to pass, which is run with 32-bit pointers, the intermediate calculations must be performed using 64-bit integers. This is because, as noted in the patch, when GetLinearExpression decomposes an expression into C1*V+C2, and we then multiply this by Scale, and distribute, to get (C1*Scale)*V + C2*Scale, it can be the case that, even through C1*V+C2 does not overflow for relevant values of V, (C2*Scale) can overflow. If this happens, later logic will draw invalid conclusions from the (base) offset value. Thus, when initially applying the APInt conversion, because the maximum pointer size in this test is 32 bits, it started failing. Suspicious, I created a 64-bit version of this test (included here), and that failed (miscompiled) on trunk for a similar reason (the multiplication can overflow). After fixing this overflow bug, the first test case (at least) in Analysis/BasicAA/q.bad.ll started failing. This is also a 32-bit test, and was relying on having 64-bit intermediate values to have BasicAA return an accurate result. In order to fix this problem, and because I believe that it is not uncommon to use i64 indexing expressions in 32-bit code (especially portable code using int64_t), it seems reasonable to always use at least 64-bit integers. In this way, we won't regress our analysis capabilities (and there's a command-line option added, so experimenting with this should be easy). As pointed out by Eli during the review, there are other potential overflow conditions that this patch does not address. Fixing those is left to follow-up work. Patch by me with contributions from Michael Ferguson (mferguson@cray.com). Differential Revision: https://reviews.llvm.org/D38662 llvm-svn: 350220
* Extend Module::getOrInsertGlobal to control the construction of thePhilip Pfaffe2019-01-021-8/+14
| | | | | | | | | | | | | | | | | | GlobalVariable Summary: Extend Module::getOrInsertGlobal to accept a callback for creating a new GlobalVariable if necessary instead of calling the GV constructor directly using default arguments. Additionally overload getOrInsertGlobal for the previous default behavior. Reviewers: chandlerc Subscribers: hiraditya, llvm-commits, bollu Differential Revision: https://reviews.llvm.org/D56130 llvm-svn: 350219
OpenPOWER on IntegriCloud