summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
* Add intrinsics for constrained floating point operationsAndrew Kaylor2017-01-262-0/+50
| | | | | | | | | | | | | | 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
* New OptimizationRemarkEmitter pass for MIRAdam Nemet2017-01-251-8/+7
| | | | | | | | | | | | | | | | | This allows MIR passes to emit optimization remarks with the same level of functionality that is available to IR passes. It also hooks up the greedy register allocator to report spills. This allows for interesting use cases like increasing interleaving on a loop until spilling of registers is observed. I still need to experiment whether reporting every spill scales but this demonstrates for now that the functionality works from llc using -pass-remarks*=<pass>. Differential Revision: https://reviews.llvm.org/D29004 llvm-svn: 293110
* [OptDiag] Split code region out of DiagnosticInfoOptimizationBaseAdam Nemet2017-01-251-18/+17
| | | | | | | | | | | | | | | | | | Code region is the only part of this class that is IR-specific. Code region is moved down in the inheritance tree to a new derived class, called DiagnosticInfoIROptimization. All the existing remarks are derived from this new class now. This allows the new MIR pass-remark classes to be derived from DiagnosticInfoOptimizationBase. Also because we keep the name DiagnosticInfoOptimizationBase, the clang parts don't need any adjustment. Differential Revision: https://reviews.llvm.org/D29003 llvm-svn: 293109
* Revert "Do not verify dominator tree if it has no roots"Chad Rosier2017-01-251-4/+0
| | | | | | | This reverts commit r293033, per Danny's comment. In short, we require domtrees to have roots at all times. llvm-svn: 293075
* Do not verify dominator tree if it has no rootsSerge Pavlov2017-01-251-0/+4
| | | | | | | | | | | If dominator tree has no roots, the pass that calculates it is likely to be skipped. It occures, for instance, in the case of entities with linkage available_externally. Do not run tree verification in such case. Differential Revision: https://reviews.llvm.org/D28767 llvm-svn: 293033
* Make VerifyDomInfo and VerifyLoopInfo global variablesSerge Pavlov2017-01-241-2/+2
| | | | | | | | | | | | | | | Verifications of dominator tree and loop info are expensive operations so they are disabled by default. They can be enabled by command line options -verify-dom-info and -verify-loop-info. These options however enable checks only in files Dominators.cpp and LoopInfo.cpp. If some transformation changes dominaror tree and/or loop info, it would be convenient to place similar checks to the files implementing the transformation. This change makes corresponding flags global, so they can be used in any file to optionally turn verification on. llvm-svn: 292889
* [IR] Use const_cast to reuse the const version of two BasicBlock methods ↵Craig Topper2017-01-221-9/+0
| | | | | | | | that are duplicated for both const and non-const. NFC Similar is already done for other methods in BasicBlock. llvm-svn: 292753
* [NVPTX] Auto-upgrade some NVPTX intrinsics to LLVM target-generic code.Justin Lebar2017-01-211-2/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Specifically, we upgrade llvm.nvvm.: * brev{32,64} * clz.{i,ll} * popc.{i,ll} * abs.{i,ll} * {min,max}.{i,ll,u,ull} * h2f These either map directly to an existing LLVM target-generic intrinsic or map to a simple LLVM target-generic idiom. In all cases, we check that the code we generate is lowered to PTX as we expect. These builtins don't need to be backfilled in clang: They're not accessible to user code from nvcc. Reviewers: tra Subscribers: majnemer, cfe-commits, llvm-commits, jholewinski Differential Revision: https://reviews.llvm.org/D28793 llvm-svn: 292694
* Reverted: Track validity of pass resultsSerge Pavlov2017-01-152-20/+5
| | | | | | Commits r291882 and related r291887. llvm-svn: 292062
* [PM] Introduce an analysis set used to preserve all analyses overChandler Carruth2017-01-152-0/+11
| | | | | | | | | | | | | | | a function's CFG when that CFG is unchanged. This allows transformation passes to simply claim they preserve the CFG and analysis passes to check for the CFG being preserved to remove the fanout of all analyses being listed in all passes. I've gone through and removed or cleaned up as many of the comments reminding us to do this as I could. Differential Revision: https://reviews.llvm.org/D28627 llvm-svn: 292054
* [IR] Don't call assertModuleIsMaterialized in release buildsCraig Topper2017-01-131-1/+1
| | | | | | | | | | | | | | | | | Summary: To fix a release vs debug build linking error, r259695 made the body of assertModuleIsMaterialized empty if Value.cpp gets compiled in a release build. This way any code compiled as a debug build can still link against a release version of the function. This patch takes this a step farther and removes all calls to it from Value.h in any code that includes it in a relase build. This shrinks the opt binary on my macbook build by 17240 bytes. Reviewers: rafael Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28191 llvm-svn: 291883
* Track validity of pass resultsSerge Pavlov2017-01-132-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | Running tests with expensive checks enabled exhibits some problems with verification of pass results. First, the pass verification may require results of analysis that are not available. For instance, verification of loop info requires results of dominator tree analysis. A pass may be marked as conserving loop info but does not need to be dependent on DominatorTreePass. When a pass manager tries to verify that loop info is valid, it needs dominator tree, but corresponding analysis may be already destroyed as no user of it remained. Another case is a pass that is skipped. For instance, entities with linkage available_externally do not need code generation and such passes are skipped for them. In this case result verification must also be skipped. To solve these problems this change introduces a special flag to the Pass structure to mark passes that have valid results. If this flag is reset, verifications dependent on the pass result are skipped. Differential Revision: https://reviews.llvm.org/D27190 llvm-svn: 291882
* [DebugInfo] Added DI macro creation API to DIBuilder.Amjad Aboud2017-01-121-0/+44
| | | | | | Differential Revision: https://reviews.llvm.org/D16077 llvm-svn: 291769
* Move the section name from GlobalObject to the LLVMContextReid Kleckner2017-01-102-4/+29
| | | | | | | | | | | | | | | | | | | | | | | Summary: Convention wisdom says that bytes in Function are precious, and the vast, vast majority of globals do not live in special sections. Even when they do, they tend to live in the same section. Store the section name on the LLVMContext in a StringSet, and maintain a map from GlobalObject* to section name like we do for metadata, prefix data, etc. The fact that we've survived this long wasting at least three pointers of space in Function suggests that Function bytes are perhaps not as precious as we once thought. Given that most functions have metadata attachments when debug info is enabled, we might consider adding a pointer here to make that access more efficient. Reviewers: jlebar, dexonsmith, mehdi_amini Subscribers: mehdi_amini, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D28150 llvm-svn: 291613
* [ARM] Remove rbit intrinsics and autoupgrade to generic bitreverse.Chad Rosier2017-01-101-1/+1
| | | | | | Testing already covered by CodeGen/ARM/rbit.ll llvm-svn: 291587
* [AArch64] Add support for lowering bitreverse to the rbit instruction.Chad Rosier2017-01-101-0/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D28379 llvm-svn: 291575
* [AVX-512] Remove vinsert intrinsics and autoupgrade to native ↵Craig Topper2017-01-031-15/+23
| | | | | | shufflevectors. There are some codegen problems here that I'll try to fix in future commits. llvm-svn: 290864
* [AVX-512] Remove vextract intrinsics and autoupgrade to native ↵Craig Topper2017-01-031-10/+16
| | | | | | | | shufflevectors. This unfortunately generates some really terrible code without VLX support due to v2i1 and v4i1 not being legal. Hopefully we can improve that in future patches. llvm-svn: 290863
* [TBAAVerifier] Be stricter around verifying scalar nodesSanjoy Das2016-12-291-24/+21
| | | | | | | | | | | This fixes the issue exposed in PR31393, where we weren't trying sufficiently hard to diagnose bad TBAA metadata. This does reduce the variety in the error messages we print out, but I think the tradeoff of verifying more, simply and quickly overrules the need for more helpful error messags here. llvm-svn: 290713
* [TBAAVerifier] Make things const-consistent; NFCSanjoy Das2016-12-291-6/+6
| | | | llvm-svn: 290712
* [TBAAVerifier] Memoize validity of scalar tbaa nodes; NFCISanjoy Das2016-12-291-5/+14
| | | | llvm-svn: 290711
* Introduce element-wise atomic memcpy intrinsicIgor Laevsky2016-12-291-0/+26
| | | | | | | | | | This change adds a new intrinsic which is intended to provide memcpy functionality with additional atomicity guarantees. Please refer to the review thread or language reference for further details. Differential Revision: https://reviews.llvm.org/D27133 llvm-svn: 290708
* Add a static_assert about the sizeof(GlobalValue)Reid Kleckner2016-12-291-0/+7
| | | | | | | | I added one for Value back in r262045, and I'm starting to think we should have these for any class with bitfields whose memory efficiency really matters. llvm-svn: 290698
* Speed up Function::isIntrinsic() by adding a bit to GlobalValue. NFCJustin Lebar2016-12-281-3/+6
| | | | | | | | | | | | | | | | | | Summary: Previously isIntrinsic() called getName(). This involves a hashtable lookup, so is nontrivially expensive. And isIntrinsic() is called frequently, particularly by dyn_cast<IntrinsicInstr>. This patch steals a bit of IntID and uses that to store whether or not getName() starts with "llvm." Reviewers: bogner, arsenm, joker-eph Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D22949 llvm-svn: 290691
* [PM] Introduce the facilities for registering cross-IR-unit dependenciesChandler Carruth2016-12-271-5/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that require deferred invalidation. This handles the other real-world invalidation scenario that we have cases of: a function analysis which caches references to a module analysis. We currently do this in the AA aggregation layer and might well do this in other places as well. Since this is relative rare, the technique is somewhat more cumbersome. Analyses need to register themselves when accessing the outer analysis manager's proxy. This proxy is already necessarily present to allow access to the outer IR unit's analyses. By registering here we can track and trigger invalidation when that outer analysis goes away. To make this work we need to enhance the PreservedAnalyses infrastructure to support a (slightly) more explicit model for "sets" of analyses, and allow abandoning a single specific analyses even when a set covering that analysis is preserved. That allows us to describe the scenario of preserving all Function analyses *except* for the one where deferred invalidation has triggered. We also need to teach the invalidator API to support direct ID calls instead of always going through a template to dispatch so that we can just record the ID mapping. I've introduced testing of all of this both for simple module<->function cases as well as for more complex cases involving a CGSCC layer. Much like the previous patch I've not tried to fully update the loop pass management layer because that layer is due to be heavily reworked to use similar techniques to the CGSCC to handle updates. As that happens, we'll have a better testing basis for adding support like this. Many thanks to both Justin and Sean for the extensive reviews on this to help bring the API design and documentation into a better state. Differential Revision: https://reviews.llvm.org/D27198 llvm-svn: 290594
* [AVX-512] Remove masked pmuldq and pmuludq intrinsics and autoupgrade them ↵Craig Topper2016-12-271-0/+26
| | | | | | to unmasked intrinsics plus a select. llvm-svn: 290583
* [DebugInfo] Added support for Checksum debug info feature.Amjad Aboud2016-12-255-11/+53
| | | | | | Differential Revision: https://reviews.llvm.org/D27642 llvm-svn: 290514
* Refactor the DIExpression fragment query interface (NFC)Adrian Prantl2016-12-222-19/+12
| | | | | | ... so it becomes available to DIExpressionCursor. llvm-svn: 290322
* [AsmWriter] Remove redundant cast<>s. NFC.Ahmed Bougacha2016-12-211-2/+2
| | | | llvm-svn: 290283
* Reapply r289926: attempt to fix windows buildAdrian Prantl2016-12-201-1/+2
| | | | llvm-svn: 290158
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-207-47/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-167-119/+47
| | | | | | | | | | | | | | | | | This reverts commit 289920 (again). I forgot to implement a Bitcode upgrade for the case where a DIGlobalVariable has not DIExpression. Unfortunately it is not possible to safely upgrade these variables without adding a flag to the bitcode record indicating which version they are. My plan of record is to roll the planned follow-up patch that adds a unit: field to DIGlobalVariable into this patch before recomitting. This way we only need one Bitcode upgrade for both changes (with a version flag in the bitcode record to safely distinguish the record formats). Sorry for the churn! llvm-svn: 289982
* Move VerifierSupport into namespace llvm.Daniel Jasper2016-12-161-1/+5
| | | | | | | | | It currently is in an unnamed namespace and then it shouldn't be used from something in the header file. This actually triggers a warning with GCC: ../include/llvm/IR/Verifier.h:39:7: warning: ‘llvm::TBAAVerifier’ has a field ‘llvm::TBAAVerifier::Diagnostic’ whose type uses the anonymous namespace [enabled by default] llvm-svn: 289942
* Extract a TBAAVerifier out of the verifier (NFC)Mehdi Amini2016-12-161-268/+268
| | | | | | | | | | | This is intended to be used (in a later patch) by the BitcodeReader to detect invalid TBAA and drop them when loading bitcode, so that we don't break client that have legacy bitcode with possible invalid TBAA. Differential Revision: https://reviews.llvm.org/D27838 llvm-svn: 289927
* attempt to fix windows buildNico Weber2016-12-161-1/+2
| | | | llvm-svn: 289926
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-167-47/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289920
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-167-119/+47
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-167-47/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289902
* [Verifier] Allow TBAA metadata on atomicrmw and atomiccmpxchgSanjoy Das2016-12-151-1/+2
| | | | | | | | | This used to be allowed before r289402 by default (before r289402 you could have TBAA metadata on any instruction), and while I'm not sure that it helps, it does sound reasonable enough to not fail the verifier and we have out-of-tree users who use this. llvm-svn: 289872
* [DebugInfo] Changed DIBuilder::createCompileUnit() to take DIFile instead of ↵Amjad Aboud2016-12-141-7/+5
| | | | | | | | | | | | FileName and Directory. This way it will be easier to expand DIFile (e.g., to contain checksum) without the need to modify the createCompileUnit() API. Reviewers: llvm-commits, rnk Differential Revision: https://reviews.llvm.org/D27762 llvm-svn: 289702
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-146-61/+61
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* [Verifier] Add verification for TBAA metadataSanjoy Das2016-12-111-2/+265
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
* [Constants] don't die processing non-ConstantInt GEP indices in ↵Sanjay Patel2016-12-111-6/+8
| | | | | | | | | isGEPWithNoNotionalOverIndexing() (PR31262) This should fix: https://llvm.org/bugs/show_bug.cgi?id=31262 llvm-svn: 289401
* [X86] Remove masking from 512-bit VPERMIL intrinsics in preparation for ↵Craig Topper2016-12-111-4/+5
| | | | | | being able to constant fold them in InstCombineCalls like we do for 128/256-bit. llvm-svn: 289350
* [X86] Remove masking from 512-bit PSHUFB intrinsics in preparation for being ↵Craig Topper2016-12-101-2/+3
| | | | | | able to constant fold it in InstCombineCalls like we do for 128/256-bit. llvm-svn: 289344
* [AVX-512] Remove 128/256 masked vpermil instrinsics and autoupgrade to a ↵Craig Topper2016-12-101-0/+22
| | | | | | select around the unmasked avx1 intrinsics. llvm-svn: 289340
* [X86][IR] Move the autoupgrading of store intrinsics out of the main nested ↵Craig Topper2016-12-101-90/+102
| | | | | | | | if/else chain. This should buy a little more time against the MSVC limit mentioned in PR31034. The handlers for stores all return at the end of their block so they can be picked off early. llvm-svn: 289339
* [PM] Support invalidation of inner analysis managers from a pass over the ↵Chandler Carruth2016-12-101-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | outer IR unit. Summary: This never really got implemented, and was very hard to test before a lot of the refactoring changes to make things more robust. But now we can test it thoroughly and cleanly, especially at the CGSCC level. The core idea is that when an inner analysis manager proxy receives the invalidation event for the outer IR unit, it needs to walk the inner IR units and propagate it to the inner analysis manager for each of those units. For example, each function in the SCC needs to get an invalidation event when the SCC gets one. The function / module interaction is somewhat boring here. This really becomes interesting in the face of analysis-backed IR units. This patch effectively handles all of the CGSCC layer's needs -- both invalidating SCC analysis and invalidating function analysis when an SCC gets invalidated. However, this second aspect doesn't really handle the LoopAnalysisManager well at this point. That one will need some change of design in order to fully integrate, because unlike the call graph, the entire function behind a LoopAnalysis's results can vanish out from under us, and we won't even have a cached API to access. I'd like to try to separate solving the loop problems into a subsequent patch though in order to keep this more focused so I've adapted them to the API and updated the tests that immediately fail, but I've not added the level of testing and validation at that layer that I have at the CGSCC layer. An important aspect of this change is that the proxy for the FunctionAnalysisManager at the SCC pass layer doesn't work like the other proxies for an inner IR unit as it doesn't directly manage the FunctionAnalysisManager and invalidation or clearing of it. This would create an ever worsening problem of dual ownership of this responsibility, split between the module-level FAM proxy and this SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy to work in terms of the module-level proxy and defer to it to handle much of the updates. It only does SCC-specific invalidation. This will become more important in subsequent patches that support more complex invalidaiton scenarios. Reviewers: jlebar Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits Differential Revision: https://reviews.llvm.org/D27197 llvm-svn: 289317
* IR, X86: Understand !absolute_symbol metadata on global variables.Peter Collingbourne2016-12-082-0/+22
| | | | | | | | | | | | | | | | | Summary: Attaching !absolute_symbol to a global variable does two things: 1) Marks it as an absolute symbol reference. 2) Specifies the value range of that symbol's address. Teach the X86 backend to allow absolute symbols to appear in place of immediates by extending the relocImm and mov64imm32 matchers. Start using relocImm in more places where it is legal. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/105800.html Differential Revision: https://reviews.llvm.org/D25878 llvm-svn: 289087
* [ADT, IR] Fix some Clang-tidy modernize-use-equals-delete and Include What ↵Eugene Zelenko2016-12-073-75/+151
| | | | | | You Use warnings; other minor fixes (NFC). llvm-svn: 288989
OpenPOWER on IntegriCloud