summaryrefslogtreecommitdiffstats
path: root/llvm/test/Feature
Commit message (Collapse)AuthorAgeFilesLines
* Restore the LoopInstSimplify pass, reverting r327329 that removed it.Chandler Carruth2018-05-251-1/+2
| | | | | | | | | | | | | | | The plan had always been to move towards using this rather than so much in-pass simplification within the loop pipeline, but we never got around to it.... until only a couple months after it was removed due to disuse. =/ This commit is just a pure revert of the removal. I will add tests and do some basic cleanup in follow-up commits. Then I'll wire it into the loop pass pipeline. Differential Revision: https://reviews.llvm.org/D47353 llvm-svn: 333250
* Remove the LoopInstSimplify pass (-loop-instsimplify)Vedant Kumar2018-03-121-2/+1
| | | | | | | | | | | | LoopInstSimplify is unused and untested. Reading through the commit history the pass also seems to have a high maintenance burden. It would be best to retire the pass for now. It should be easy to recover if we need something similar in the future. Differential Revision: https://reviews.llvm.org/D44053 llvm-svn: 327329
* Mark two tests REQUIRES: x86-registered-backendJustin Bogner2018-01-311-0/+1
| | | | | | | | These were introduced in r323783 and use an X86 triple. I'll follow up on the list to check if it would make more sense to remove the triple and mark them REQUIRES: default_triple instead. llvm-svn: 323847
* CodeGen: support an extension to pass linker options on ELFSaleem Abdulrasool2018-01-301-0/+16
| | | | | | | | | | | | | | | | | | Introduce an extension to support passing linker options to the linker. These would be ignored by older linkers, but newer linkers which support this feature would be able to process the linker. Emit a special discarded section `.linker-option`. The content of this section is a pair of strings (key, value). The key is a type identifier for the parameter. This allows for an argument free parameter that will be processed by the linker with the value being the parameter. As an example, `lib` identifies a library to be linked against, traditionally the `-l` argument for Unix-based linkers with the parameter being the library name. Thanks to James Henderson, Cary Coutant, Rafael Espinolda, Sean Silva for the valuable discussion on the design of this feature. llvm-svn: 323783
* Add ‘llvm.experimental.constrained.fma‘ Intrinsic.Wei Ding2017-08-241-2/+14
| | | | | | Differential Revision: http://reviews.llvm.org/D36335 llvm-svn: 311629
* LowerAtomic: Don't skip optnone functions; atomic still need lowering (PR34020)Hans Wennborg2017-08-231-1/+0
| | | | | | | | | | | The lowering isn't really an optimization, so optnone shouldn't make a difference. ARM relies on the pass running when using "-mthread-model single", because in that mode, it doesn't run AtomicExpand. See bug for more details. Differential Revision: https://reviews.llvm.org/D37040 llvm-svn: 311565
* Remove the BBVectorize pass.Chandler Carruth2017-06-301-2/+1
| | | | | | | | | | | | | It served us well, helped kick-start much of the vectorization efforts in LLVM, etc. Its time has come and past. Back in 2014: http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html Time to actually let go and move forward. =] I've updated the release notes both about the removal and the deprecation of the corresponding C API. llvm-svn: 306797
* Add constrained intrinsics for some libm-equivalent operationsAndrew Kaylor2017-05-251-0/+148
| | | | | | Differential revision: https://reviews.llvm.org/D32319 llvm-svn: 303922
* Test for r303197Matthias Braun2017-05-161-0/+1
| | | | llvm-svn: 303208
* Add "REQUIRES:" to the last few tests that use target specific intrinsicsJustin Bogner2017-05-151-0/+1
| | | | llvm-svn: 303123
* Replace hardcoded intrinsic list with speculatable attribute.Matt Arsenault2017-05-031-1/+1
| | | | | | No change in which intrinsics should be speculated. llvm-svn: 301995
* Disable GVN Hoist due to still more bugs being found in it. There isChandler Carruth2017-04-271-2/+0
| | | | | | | | | | also a discussion about exactly what we should do prior to re-enabling it. The current bug is http://llvm.org/PR32821 and the discussion about this is in the review thread for r300200. llvm-svn: 301505
* [GVNHoist] Re-enable GVNHoist by defaultGeoff Berry2017-04-111-0/+1
| | | | | | Turn GVNHoist back on by default now that PR32153 has been fixed. llvm-svn: 299944
* Disable gvn-hoist (PR32153)Hans Wennborg2017-03-061-1/+0
| | | | llvm-svn: 297075
* Add intrinsics for constrained floating point operationsAndrew Kaylor2017-01-261-0/+102
| | | | | | | | | | | | | | This commit introduces a set of experimental intrinsics intended to prevent optimizations that make assumptions about the rounding mode and floating point exception behavior. These intrinsics will later be extended to specify flush-to-zero behavior. More work is also required to model instruction dependencies in machine code and to generate these instructions from clang (when required by pragmas and/or command line options that are not currently supported). Differential Revision: https://reviews.llvm.org/D27028 llvm-svn: 293226
* Fix some broken CHECK lines.Benjamin Kramer2017-01-221-1/+1
| | | | | | The colon is important. llvm-svn: 292761
* Revert "Revert "Invariant start/end intrinsics overloaded for address space""Mehdi Amini2016-08-131-4/+4
| | | | | | This reverts commit 32fc6488e48eafc0ca1bac1bd9cbf0008224d530. llvm-svn: 278609
* Revert "Invariant start/end intrinsics overloaded for address space"Mehdi Amini2016-08-131-4/+4
| | | | | | This reverts commit r276447. llvm-svn: 278608
* GVN-hoist: enable by defaultSebastian Pop2016-08-081-0/+1
| | | | llvm-svn: 278010
* Revert "(refs/bisect/bad) GVN-hoist: enable by default"Matthias Braun2016-08-061-1/+0
| | | | | | | | | | | GVN-Hoist appears to miscompile llvm-testsuite SingleSource/Benchmarks/Misc/fbench.c at the moment. I filed http://llvm.org/PR28880 This reverts commit r277786. llvm-svn: 277909
* GVN-hoist: enable by defaultSebastian Pop2016-08-041-0/+1
| | | | llvm-svn: 277786
* Revert "GVN-hoist: enable by default" & "Make GVN Hoisting obey optnone/bisect."Bruno Cardoso Lopes2016-08-041-1/+0
| | | | | | | | This reverts commits r277685 & r277688. r277685 broke compiler-rt compilation http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/23335 and r277685 is a followup from it. llvm-svn: 277690
* Make GVN Hoisting obey optnone/bisect.Sebastian Pop2016-08-041-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D23136 llvm-svn: 277688
* Reinstate optnone test for GVN Hoisting, removed in r276479.Paul Robinson2016-07-291-1/+2
| | | | llvm-svn: 277158
* Add flag to PassManagerBuilder to disable GVN Hoist Pass.Alina Sbirlea2016-07-221-1/+0
| | | | | | | | | | | | | | Summary: Adding a flag to diable GVN Hoisting by default. Note: The GVN Hoist Pass causes some Halide tests to hang. Halide will disable the pass while investigating. Reviewers: llvm-commits, chandlerc, spop, dberlin Subscribers: mehdi_amini Differential Revision: https://reviews.llvm.org/D22639 llvm-svn: 276479
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-221-4/+4
| | | | | | | | | | | | | | | | | | | | | | 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-4/+4
| | | | | | This reverts commit r276316. llvm-svn: 276320
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-211-4/+4
| | | | | | | | | | | | | | | | | | | | | 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
* Make GVN Hoisting obey optnone/bisect.Paul Robinson2016-07-191-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D22545 llvm-svn: 276048
* Temporarily remove a test case to unblock PPC bots.Andrew Kaylor2016-07-081-1/+0
| | | | llvm-svn: 274813
* NVPTX: Replace uses of cuda.syncthreads with nvvm.barrier0Justin Bogner2016-07-061-3/+3
| | | | | | | Everywhere where cuda.syncthreads or __syncthreads is used, use the properly namespaced nvvm.barrier0 instead. llvm-svn: 274664
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* Update the stack coloring pass to remove lifetime intrinsics in the ↵Andrew Kaylor2016-05-271-1/+0
| | | | | | | | optnone/opt-bisect skip case. Differential Revision: http://reviews.llvm.org/D20453 llvm-svn: 271068
* Make "@name =" mandatory for globals in .ll files.Rafael Espindola2016-05-104-13/+13
| | | | | | | | | | | | | | | | | | | | | | | An oddity of the .ll syntax is that the "@var = " in @var = global i32 42 is optional. Writing just global i32 42 is equivalent to @0 = global i32 42 This means that there is a pretty big First set at the top level. The current implementation maintains it manually. I was trying to refactor it, but then started wondering why keep it a all. I personally find the above syntax confusing. It looks like something is missing. This patch removes the feature and simplifies the parser. llvm-svn: 269096
* [NVVM] Remove noduplicate attribute from synchronizing intrinsics.Justin Lebar2016-03-221-2/+2
| | | | | | | | | | | | | | | Summary: I've completed my audit of all the code that looks at noduplicate and added handling of convergent where appropriate, so we no longer need noduplicate on these intrinsics. Reviewers: jholewinski Subscribers: llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D18168 llvm-svn: 264107
* Add a flag to the LLVMContext to disable name for Value other than GlobalValueMehdi Amini2016-03-101-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is intended to be a performance flag, on the same level as clang cc1 option "--disable-free". LLVM will never initialize it by default, it will be up to the client creating the LLVMContext to request this behavior. Clang will do it by default in Release build (just like --disable-free). "opt" and "llc" can opt-in using -disable-named-value command line option. When performing LTO on llvm-tblgen, the initial merging of IR peaks at 92MB without this patch, and 86MB after this patch,setNameImpl() drops from 6.5MB to 0.5MB. The total link time goes from ~29.5s to ~27.8s. Compared to a compile-time flag (like the IRBuilder one), it performs very close. I profiled on SROA and obtain these results: 420ms with IRBuilder that preserve name 372ms with IRBuilder that strip name 375ms with IRBuilder that preserve name, and a runtime flag to strip Reviewers: chandlerc, dexonsmith, bogner Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17946 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263086
* [GMR/OperandBundles] Teach getModRefBehavior about operand bundlesSanjoy Das2016-02-091-0/+27
| | | | | | | | | In general, memory restrictions on a called function (e.g. readnone) cannot be transferred to a CallSite that has operand bundles. It is possible to make this inference smarter, but lets fix the behavior to be correct first. llvm-svn: 260193
* [NVPTX] Mark nvvm synchronizing intrinsics as convergent.Justin Lebar2016-02-061-2/+2
| | | | | | | | | | | | | | | Summary: This is the attribute purpose-made for e.g. __syncthreads. It appears that NoDuplicate may not be sufficient to prevent Sink from touching a call to __syncthreads. Reviewers: jingyue, hfinkel Subscribers: llvm-commits, jholewinski, jhen, rnk, tra, majnemer Differential Revision: http://reviews.llvm.org/D16941 llvm-svn: 260005
* MachineScheduler: Honor optnone functions in the pre-ra scheduler.Chad Rosier2016-01-201-0/+1
| | | | llvm-svn: 258363
* [WinEH] Verify unwind edges against EH pad treeJoseph Tremoulet2016-01-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Funclet EH personalities require a tree-like nesting among funclets (enforced by the ParentPad linkage in the IR), and also require that unwind edges conform to certain rules with respect to the tree: - An unwind edge may exit 0 or more ancestor pads - An unwind edge must enter exactly one EH pad, which must be distinct from any exited pads - A cleanupret's edge must exit its cleanuppad Describe these rules in the LangRef, and enforce them in the verifier. Reviewers: rnk, majnemer, andrew.w.kaylor Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15961 llvm-svn: 257272
* [MergeFunctions] Use II instead of CI for InvokeInst; NFCSanjoy Das2015-12-141-0/+30
| | | | | | Using `CI` is slightly misleading. llvm-svn: 255529
* Teach MergeFunctions about operand bundlesSanjoy Das2015-12-141-0/+34
| | | | llvm-svn: 255528
* Teach haveSameSpecialState about operand bundlesSanjoy Das2015-12-141-0/+21
| | | | llvm-svn: 255527
* [IR] Remove terminatepadDavid Majnemer2015-12-141-22/+0
| | | | | | | | | | | | | It turns out that terminatepad gives little benefit over a cleanuppad which calls the termination function. This is not sufficient to implement fully generic filters but MSVC doesn't support them which makes terminatepad a little over-designed. Depends on D15478. Differential Revision: http://reviews.llvm.org/D15479 llvm-svn: 255522
* [IR] Reformulate LLVM's EH funclet IRDavid Majnemer2015-12-121-101/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
* Have 'optnone' respect the -fast-isel=false option.Paul Robinson2015-11-301-1/+7
| | | | | | | | This is primarily useful for debugging optnone v. ISel issues. Differential Revision: http://reviews.llvm.org/D14792 llvm-svn: 254335
* [OperandBundles] Treat "deopt" operand bundles speciallySanjoy Das2015-11-265-2/+93
| | | | | | | | | Teach LLVM optimize to more precisely in the presence of "deopt" operand bundles. "deopt" operand bundles imply that the call they're attached to is at least `readonly` (i.e. they don't imply clobber semantics), and they don't capture their bundle operands. llvm-svn: 254118
* [FunctionAttrs] Add handling for operand bundlesSanjoy Das2015-11-071-0/+24
| | | | | | | | | | | | | | Summary: Teach the FunctionAttrs to do the right thing for IR with operand bundles. Reviewers: reames, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14408 llvm-svn: 252387
* [CaptureTracking] Support operand bundles conservativelySanjoy Das2015-11-041-0/+29
| | | | | | | | | | | | | | | | | | | | | Summary: Earlier CaptureTracking would assume all "interesting" operands to a call or invoke were its arguments. With operand bundles this is no longer true. Note: an earlier change got `doesNotCapture` working correctly with operand bundles. This change uses DSE to test the changes to CaptureTracking. DSE is a vehicle for testing only, and is not directly involved in this change. Reviewers: reames, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14306 llvm-svn: 252095
* [Inliner] Don't inline through callsites with operand bundlesSanjoy Das2015-10-231-0/+17
| | | | | | | | | | | | | | | | Summary: This change teaches the LLVM inliner to not inline through callsites with unknown operand bundles. Currently all operand bundles are "unknown" operand bundles but in the near future we will add support for inlining through some select kinds of operand bundles. Reviewers: reames, chandlerc, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14001 llvm-svn: 251141
OpenPOWER on IntegriCloud