summaryrefslogtreecommitdiffstats
path: root/llvm/test/Assembler/auto_upgrade_intrinsics.ll
Commit message (Collapse)AuthorAgeFilesLines
* Allow prefetching from non-zero address spacesJF Bastien2019-07-251-0/+15
| | | | | | | | | | | | | | | Summary: This is useful for targets which have prefetch instructions for non-default address spaces. <rdar://problem/42662136> Subscribers: nemanjai, javed.absar, hiraditya, kbarton, jkorous, dexonsmith, cfe-commits, llvm-commits, RKSimon, hfinkel, t.p.northover, craig.topper, anemet Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65254 llvm-svn: 367032
* Verifier: Make sure masked load/store alignment is a power of 2Matt Arsenault2019-03-131-1/+1
| | | | | | | The same should also be done for scatter/gather, but the verifier doesn't check those at all now. llvm-svn: 356094
* IR: Add immarg attributeMatt Arsenault2019-03-121-2/+2
| | | | | | | | | | | | | | | | | This indicates an intrinsic parameter is required to be a constant, and should not be replaced with a non-constant value. Add the attribute to all AMDGPU and generic intrinsics that comments indicate it should apply to. I scanned other target intrinsics, but I don't see any obvious comments indicating which arguments are intended to be only immediates. This breaks one questionable testcase for the autoupgrade. I'm unclear on whether the autoupgrade is supposed to really handle declarations which were never valid. The verifier fails because the attributes now refer to a parameter past the end of the argument list. llvm-svn: 355981
* Add a 'dynamic' parameter to the objectsize intrinsicErik Pilkington2019-01-301-3/+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
* Support arbitrary address space pointers in masked gather/scatter intrinsics.Elad Cohen2017-05-031-0/+17
| | | | | | | | | | | | Fixes PR31789 - When loop-vectorize tries to use these intrinsics for a non-default address space pointer we fail with a "Calling a function with a bad singature!" assertion. This patch solves this by adding the 'vector of pointers' argument as an overloaded type which will determine the address space. Differential revision: https://reviews.llvm.org/D31490 llvm-svn: 302018
* Add address space mangling to lifetime intrinsicsMatt Arsenault2017-04-101-0/+19
| | | | | | In preparation for allowing allocas to have non-0 addrspace. llvm-svn: 299876
* Let llvm.objectsize be conservative with null pointersGeorge Burgess IV2017-03-211-1/+10
| | | | | | | | | | | This adds a parameter to @llvm.objectsize that makes it return conservative values if it's given null. This fixes PR23277. Differential Revision: https://reviews.llvm.org/D28494 llvm-svn: 298430
* Revert "Revert "Invariant start/end intrinsics overloaded for address space""Mehdi Amini2016-08-131-0/+15
| | | | | | This reverts commit 32fc6488e48eafc0ca1bac1bd9cbf0008224d530. llvm-svn: 278609
* Revert "Invariant start/end intrinsics overloaded for address space"Mehdi Amini2016-08-131-15/+0
| | | | | | This reverts commit r276447. llvm-svn: 278608
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-221-0/+15
| | | | | | | | | | | | | | | | | | | | | | Summary: The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. Reviewers: apilipenko, reames Subscribers: llvm-commits llvm-svn: 276447
* Revert "Invariant start/end intrinsics overloaded for address space"Anna Thomas2016-07-211-15/+0
| | | | | | This reverts commit r276316. llvm-svn: 276320
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-211-0/+15
| | | | | | | | | | | | | | | | | | | | | Summary: The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. Reviewers: tstellarAMD, reames, apilipenko Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D22519 llvm-svn: 276316
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-06-281-0/+18
| | | | | | | | | | | | | | This is a resubmittion of 263158 change after fixing the existing problem with intrinsics mangling (see LTO and intrinsics mangling llvm-dev thread for details). This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 274043
* Revert -r273892 "Support arbitrary addrspace pointers in masked load/store ↵Artur Pilipenko2016-06-271-18/+0
| | | | | | intrinsics" since some of the clang tests don't expect to see the updated signatures. llvm-svn: 273895
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-06-271-0/+18
| | | | | | | | | | | | | | This is a resubmittion of 263158 change after fixing the existing problem with intrinsics mangling (see LTO and intrinsics mangling llvm-dev thread for details). This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 273892
* Revert "Support arbitrary addrspace pointers in masked load/store intrinsics"Adam Nemet2016-04-141-19/+0
| | | | | | | | This reverts commit r266086. It breaks the LTO build of gcc in SPEC2000. llvm-svn: 266282
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-04-121-0/+19
| | | | | | | | | | | | | | This is a resubmittion of 263158 change. This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 266086
* [SSP] Remove llvm.stackprotectorcheck.Tim Shen2016-04-081-1/+14
| | | | | | | | | | This is a cleanup patch for SSP support in LLVM. There is no functional change. llvm.stackprotectorcheck is not needed, because SelectionDAG isn't actually lowering it in SelectBasicBlock; rather, it adds check code in FinishBasicBlock, ignoring the position where the intrinsic is inserted (See FindSplitPointForStackProtector()). llvm-svn: 265851
* Revert "Support arbitrary addrspace pointers in masked load/store intrinsics"Matthias Braun2016-03-221-22/+1
| | | | | | | | | | | This commit broke LTO builds. Reverting it to unbreak the bots while the issue is investigated. See also: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160321/341002.html This reverts r263158 llvm-svn: 264088
* Upgrade TBAA *before* upgrading intrinsicsChris Bieneman2016-03-161-3/+7
| | | | | | | | | | | | Summary: If TBAA is on an intrinsic and it gets upgraded and drops the TBAA we hit an odd assert. We should just upgrade the TBAA first because it doesn't have side-effects. Reviewers: reames, apilipenko, manmanren Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18229 llvm-svn: 263673
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-03-101-1/+18
| | | | | | | | | | | | This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 263158
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gep operator Similar to gep (r230786) and load (r230794) changes. Similar migration script can be used to update test cases, which successfully migrated all of LLVM and Polly, but about 4 test cases needed manually changes in Clang. (this script will read the contents of stdin and massage it into stdout - wrap it in the 'apply.sh' script shown in previous commits + xargs to apply it over a large set of test cases) import fileinput import sys import re rep = re.compile(r"(getelementptr(?:\s+inbounds)?\s*\()((<\d*\s+x\s+)?([^@]*?)(|\s*addrspace\(\d+\))\s*\*(?(3)>)\s*)(?=$|%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|zeroinitializer|<|\[\[[a-zA-Z]|\{\{)", re.MULTILINE | re.DOTALL) def conv(match): line = match.group(1) line += match.group(4) line += ", " line += match.group(2) return line line = sys.stdin.read() off = 0 for match in re.finditer(rep, line): sys.stdout.write(line[off:match.start()]) sys.stdout.write(conv(match)) off = match.end() sys.stdout.write(line[off:]) llvm-svn: 232184
* verify-uselistorder: Force -preserve-bc-use-list-orderDuncan P. N. Exon Smith2014-08-191-1/+1
| | | | llvm-svn: 216022
* verify-uselistorder: Change the default -num-shuffles=5Duncan P. N. Exon Smith2014-07-311-1/+1
| | | | | | | Change the default for `-num-shuffles` to 5 and better document the algorithm in the header docs of `verify-uselistorder`. llvm-svn: 214419
* verify-uselistorder: Add RUN lines to cases in test/AssemblyDuncan P. N. Exon Smith2014-07-311-0/+1
| | | | | | | | | | | | | | | | | Add RUN line for `verify-uselistorder` to every test in `test/Assembly`, unless it's a negative check (assembler rejects it) or verification fails. There are three files that verification fails on (so I've left out the RUN lines): - 2002-08-22-DominanceProblem.ll - ConstantExprFold.ll - ConstantExprFoldCast.ll This is part of PR5680. llvm-svn: 214365
* Change objectsize intrinsic to accept different address spaces.Matt Arsenault2013-10-071-0/+15
| | | | | | | Bitcasting everything to i8* won't work. Autoupgrade the old intrinsic declarations to use the new mangling. llvm-svn: 192117
* Add an explicit test of the auto-upgrade functionality for the newChandler Carruth2011-12-121-0/+44
intrinsic syntax. Now that this is explicitly covered, I plan to upgrade the existing test suite to use an explicit immediate. Note that I plan to specify 'true' in most places rather than the auto-upgraded value as that is the far more common value to end up here as that is the value coming from GCC's builtins. The only place I'm likely to put a 'false' in is when testing x86 which actually has different instructions for the two variants. llvm-svn: 146369
OpenPOWER on IntegriCloud