summaryrefslogtreecommitdiff
path: root/include/llvm/Transforms
Commit message (Collapse)AuthorAge
* Remove top-level Clang -fsanitize= flags for optional ASan features.Alexey Samsonov2014-06-13
| | | | | | | | | | | | | | Init-order and use-after-return modes can currently be enabled by runtime flags. use-after-scope mode is not really working at the moment. The only problem I see is that users won't be able to disable extra instrumentation for init-order and use-after-scope by a top-level Clang flag. But this instrumentation was implicitly enabled for quite a while and we didn't hear from users hurt by it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210924 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove sanitizer blacklist from ASan/TSan/MSan function passes.Alexey Samsonov2014-06-02
| | | | | | | | | | | | | | | | | | | Instrumentation passes now use attributes address_safety/thread_safety/memory_safety which are added by Clang frontend. Clang parses the blacklist file and adds the attributes accordingly. Currently blacklist is still used in ASan module pass to disable instrumentation for certain global variables. We should fix this as well by collecting the set of globals we're going to instrument in Clang and passing it to ASan in metadata (as we already do for dynamically-initialized globals and init-order checking). This change also removes -tsan-blacklist and -msan-blacklist LLVM commandline flags in favor of -fsanitize-blacklist= Clang flag. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210038 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow vectorization of intrinsics such as powi,cttz and ctlz in Loop and SLP ↵Karthik Bhat2014-05-30
| | | | | | | | | | | Vectorizer. This patch adds support to vectorize intrinsics such as powi, cttz and ctlz in Vectorizer. These intrinsics are different from other intrinsics as second argument to these function must be same in order to vectorize them and it should be represented as a scalar. Review: http://reviews.llvm.org/D3851#inline-32769 and http://reviews.llvm.org/D3937#inline-32857 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209873 91177308-0d34-0410-b5e6-96231b3b80d8
* [LoadCombine] Missed a file.Michael J. Spencer2014-05-29
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209792 91177308-0d34-0410-b5e6-96231b3b80d8
* Add LoadCombine pass.Michael J. Spencer2014-05-29
| | | | | | | | This pass is disabled by default. Use -combine-loads to enable in -O[1-3] Differential revision: http://reviews.llvm.org/D3580 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209791 91177308-0d34-0410-b5e6-96231b3b80d8
* Make the LoopRotate pass's maximum header size configurable both ↵Owen Anderson2014-05-26
| | | | | | | | | | | programmatically and via the command line, mirroring similar functionality in LoopUnroll. In situations where clients used custom unrolling thresholds, their intent could previously be foiled by LoopRotate having a hardcoded threshold. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209617 91177308-0d34-0410-b5e6-96231b3b80d8
* Reformat linefeeds.NAKAMURA Takumi2014-05-26
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209609 91177308-0d34-0410-b5e6-96231b3b80d8
* Trailing whitespace.NAKAMURA Takumi2014-05-26
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209608 91177308-0d34-0410-b5e6-96231b3b80d8
* Add an extension point for peephole optimizers.Peter Collingbourne2014-05-25
| | | | | | | | | | This extension point allows adding passes that perform peephole optimizations similar to the instruction combiner. These passes will be inserted after each instance of the instruction combiner pass. Differential Revision: http://reviews.llvm.org/D3905 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209595 91177308-0d34-0410-b5e6-96231b3b80d8
* Flip on vectorization of bswap intrinsics.Benjamin Kramer2014-05-19
| | | | | | | | | The cost model conservatively assumes that it will always get scalarized and that's about as good as we can get with the generic TTI; reasoning whether a shuffle with an efficient lowering is available is hard. We can override that conservative estimate for some targets in the future. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209125 91177308-0d34-0410-b5e6-96231b3b80d8
* Reformat blank lines.NAKAMURA Takumi2014-05-19
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209106 91177308-0d34-0410-b5e6-96231b3b80d8
* Whitespace.NAKAMURA Takumi2014-05-19
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209105 91177308-0d34-0410-b5e6-96231b3b80d8
* [modules] Add missing #include.Richard Smith2014-05-08
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208276 91177308-0d34-0410-b5e6-96231b3b80d8
* Re-commit r208025, reverted in r208030, with a fix for a conformance issueRichard Smith2014-05-06
| | | | | | | which GCC detects and Clang does not! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208033 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r208025, which made buildbots unhappy for unknown reasons.Richard Smith2014-05-06
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208030 91177308-0d34-0410-b5e6-96231b3b80d8
* Add llvm::function_ref (and a couple of uses of it), representing a ↵Richard Smith2014-05-06
| | | | | | type-erased reference to a callable object. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208025 91177308-0d34-0410-b5e6-96231b3b80d8
* Vectorize intrinsic math function calls in SLPVectorizer.Karthik Bhat2014-05-03
| | | | | | | | This patch adds support to recognize and vectorize intrinsic math functions in SLPVectorizer. Review: http://reviews.llvm.org/D3560 and http://reviews.llvm.org/D3559 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207901 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach GlobalDCE how to remove empty global_ctor entries.Nico Weber2014-05-02
| | | | | | | | | | | | | | | | | | This moves most of GlobalOpt's constructor optimization code out of GlobalOpt into Transforms/Utils/CDtorUtils.{h,cpp}. The public interface is a single function OptimizeGlobalCtorsList() that takes a predicate returning which constructors to remove. GlobalOpt calls this with a function that statically evaluates all constructors, just like it did before. This part of the change is behavior-preserving. Also add a call to this from GlobalDCE with a filter that removes global constructors that contain a "ret" instruction and nothing else – this fixes PR19590. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207856 91177308-0d34-0410-b5e6-96231b3b80d8
* Add an optimization that does CSE in a group of similar GEPs.Eli Bendersky2014-05-01
| | | | | | | | | | | | | | | | | This optimization merges the common part of a group of GEPs, so we can compute each pointer address by adding a simple offset to the common part. The optimization is currently only enabled for the NVPTX backend, where it has a large payoff on some benchmarks. Review: http://reviews.llvm.org/D3462 Patch by Jingyue Wu. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207783 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++] Use 'nullptr'. Transforms edition.Craig Topper2014-04-25
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207196 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow vectorization of bit intrinsics in BB Vectorizer.Karthik Bhat2014-04-25
| | | | | | | | This patch adds support for vectorization of bit intrinsics such as bswap,ctpop,ctlz,cttz. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207174 91177308-0d34-0410-b5e6-96231b3b80d8
* [Modules] Make Support/Debug.h modular. This requires it to not changeChandler Carruth2014-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behavior based on other files defining DEBUG_TYPE, which means it cannot define DEBUG_TYPE at all. This is actually better IMO as it forces folks to define relevant DEBUG_TYPEs for their files. However, it requires all files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't already. I've updated all such files in LLVM and will do the same for other upstream projects. This still leaves one important change in how LLVM uses the DEBUG_TYPE macro going forward: we need to only define the macro *after* header files have been #include-ed. Previously, this wasn't possible because Debug.h required the macro to be pre-defined. This commit removes that. By defining DEBUG_TYPE after the includes two things are fixed: - Header files that need to provide a DEBUG_TYPE for some inline code can do so by defining the macro before their inline code and undef-ing it afterward so the macro does not escape. - We no longer have rampant ODR violations due to including headers with different DEBUG_TYPE definitions. This may be mostly an academic violation today, but with modules these types of violations are easy to check for and potentially very relevant. Where necessary to suppor headers with DEBUG_TYPE, I have moved the definitions below the includes in this commit. I plan to move the rest of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big enough. The comments in Debug.h, which were hilariously out of date already, have been updated to reflect the recommended practice going forward. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206822 91177308-0d34-0410-b5e6-96231b3b80d8
* Add missing #include found by modules build.Richard Smith2014-04-20
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206726 91177308-0d34-0410-b5e6-96231b3b80d8
* PMBuilder: Expose an option to disable tail callsDuncan P. N. Exon Smith2014-04-18
| | | | | | | | Adds API to allow frontends to disable tail calls in PassManagerBuilder. <rdar://problem/16050591> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206542 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-15
| | | | | | instead of comparing to nullptr. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206252 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-14
| | | | | | instead of comparing to nullptr. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206142 91177308-0d34-0410-b5e6-96231b3b80d8
* SLPVectorizer: Only vectorize intrinsics whose operands are widened equallyArnold Schwaighofer2014-04-09
| | | | | | | | | The vectorizer only knows how to vectorize intrinics by widening all operands by the same factor. Patch by Tyler Nowicki! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205855 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Reapply "LTO: add API to set strategy for -internalize""Duncan P. N. Exon Smith2014-04-02
| | | | | | | | | | | This reverts commit r199244. Conflicts: include/llvm-c/lto.h include/llvm/LTO/LTOCodeGenerator.h lib/LTO/LTOCodeGenerator.cpp git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205471 91177308-0d34-0410-b5e6-96231b3b80d8
* Move partial/runtime unrolling late in the pipelineHal Finkel2014-03-31
| | | | | | | | | | | | | | | | The generic (concatenation) loop unroller is currently placed early in the standard optimization pipeline. This is a good place to perform full unrolling, but not the right place to perform partial/runtime unrolling. However, most targets don't enable partial/runtime unrolling, so this never mattered. However, even some x86 cores benefit from partial/runtime unrolling of very small loops, and follow-up commits will enable this. First, we need to move partial/runtime unrolling late in the optimization pipeline (importantly, this is after SLP and loop vectorization, as vectorization can drastically change the size of a loop), while keeping the full unrolling where it is now. This change does just that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205264 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove LowerInvoke's obsolete "-enable-correct-eh-support" optionMark Seaborn2014-03-20
| | | | | | | | | | | | | | | This option caused LowerInvoke to generate code using SJLJ-based exception handling, but there is no code left that interprets the jmp_buf stack that the resulting code maintained (llvm.sjljeh.jblist). This option has been obsolete for a while, and replaced by SjLjEHPrepare. This leaves the default behaviour of LowerInvoke, which is to convert invokes to calls. Differential Revision: http://llvm-reviews.chandlerc.com/D3136 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204388 91177308-0d34-0410-b5e6-96231b3b80d8
* [msan] Origin tracking with history.Evgeniy Stepanov2014-03-18
| | | | | | | | | LLVM part of MSan implementation of advanced origin tracking, when we record not only creation point, but all locations where an uninitialized value was stored to memory, too. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204151 91177308-0d34-0410-b5e6-96231b3b80d8
* Untabify.NAKAMURA Takumi2014-03-16
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204020 91177308-0d34-0410-b5e6-96231b3b80d8
* Move duplicated code into a helper function (exposed through overload).Eli Bendersky2014-03-12
| | | | | | | | | | | | | | | | | | | There's a bit of duplicated "magic" code in opt.cpp and Clang's CodeGen that computes the inliner threshold from opt level and size opt level. This patch moves the code to a function that lives alongside the inliner itself, providing a convenient overload to the inliner creation. A separate patch can be committed to Clang to use this once it's committed to LLVM. Standalone tools that use the inlining pass can also avoid duplicating this code and fearing it will go out of sync. Note: this patch also restructures the conditinal logic of the computation to be cleaner. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203669 91177308-0d34-0410-b5e6-96231b3b80d8
* Cloning a function now also clones its debug metadata if ↵Alon Mishne2014-03-12
| | | | | | 'ModuleLevelChanges' is true. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203662 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-05
| | | | | | class. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202953 91177308-0d34-0410-b5e6-96231b3b80d8
* [Modules] Move CFG.h to the IR library as it defines graph traits overChandler Carruth2014-03-04
| | | | | | IR types. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202827 91177308-0d34-0410-b5e6-96231b3b80d8
* [Modules] Move ValueMap to the IR library. While this class does notChandler Carruth2014-03-04
| | | | | | | | | | | | directly care about the Value class (it is templated so that the key can be any arbitrary Value subclass), it is in fact concretely tied to the Value class through the ValueHandle's CallbackVH interface which relies on the key type being some Value subclass to establish the value handle chain. Ironically, the unittest is already in the right library. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202824 91177308-0d34-0410-b5e6-96231b3b80d8
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-04
| | | | | | | | | | | Move the test for this class into the IR unittests as well. This uncovers that ValueMap too is in the IR library. Ironically, the unittest for ValueMap is useless in the Support library (honestly, so was the ValueHandle test) and so it already lives in the IR unittests. Mmmm, tasty layering. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202821 91177308-0d34-0410-b5e6-96231b3b80d8
* [Modules] Move GetElementPtrTypeIterator into the IR library. As itsChandler Carruth2014-03-04
| | | | | | | | | name might indicate, it is an iterator over the types in an instruction in the IR.... You see where this is going. Another step of modularizing the support library. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202815 91177308-0d34-0410-b5e6-96231b3b80d8
* Pass to emit DWARF path discriminators.Diego Novillo2014-03-03
| | | | | | | | | | | | | | | | DWARF discriminators are used to distinguish multiple control flow paths on the same source location. When this happens, instructions across basic block boundaries will share the same debug location. This pass detects this situation and creates a new lexical scope to one of the two instructions. This lexical scope is a child scope of the original and contains a new discriminator value. This discriminator is then picked up from MCObjectStreamer::EmitDwarfLocDirective to be written on the object file. This fixes http://llvm.org/bugs/show_bug.cgi?id=18270. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202752 91177308-0d34-0410-b5e6-96231b3b80d8
* [CodeGenPrepare] Move CodeGenPrepare into lib/CodeGen.Quentin Colombet2014-02-22
| | | | | | | | | | | | | CodeGenPrepare uses extensively TargetLowering which is part of libLLVMCodeGen. This is a layer violation which would introduce eventually a dependence on CodeGen in ScalarOpts. Move CodeGenPrepare into libLLVMCodeGen to avoid that. Follow-up of <rdar://problem/15519855> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201912 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename some member variables from TD to DL.Rafael Espindola2014-02-18
| | | | | | TargetData was renamed DataLayout back in r165242. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201581 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't build DFSan functionality for Android.Stephen Hines2014-02-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201362 91177308-0d34-0410-b5e6-96231b3b80d8
* [LPM] Fix PR18616 where the shifts to the loop pass manager to extractChandler Carruth2014-01-28
| | | | | | | | | | | | | | | | | | | | | | | | | LCSSA from it caused a crasher with the LoopUnroll pass. This crasher is really nasty. We destroy LCSSA form in a suprising way. When unrolling a loop into an outer loop, we not only need to restore LCSSA form for the outer loop, but for all children of the outer loop. This is somewhat obvious in retrospect, but hey! While this seems pretty heavy-handed, it's not that bad. Fundamentally, we only do this when we unroll a loop, which is already a heavyweight operation. We're unrolling all of these hypothetical inner loops as well, so their size and complexity is already on the critical path. This is just adding another pass over them to re-canonicalize. I have a test case from PR18616 that is great for reproducing this, but pretty useless to check in as it relies on many 10s of nested empty loops that get unrolled and deleted in just the right order. =/ What's worse is that investigating this has exposed another source of failure that is likely to be even harder to test. I'll try to come up with test cases for these fixes, but I want to get the fixes into the tree first as they're causing crashes in the wild. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200273 91177308-0d34-0410-b5e6-96231b3b80d8
* [LPM] Make LCSSA a utility with a FunctionPass that applies it to allChandler Carruth2014-01-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the loops in a function, and teach LICM to work in the presance of LCSSA. Previously, LCSSA was a loop pass. That made passes requiring it also be loop passes and unable to depend on function analysis passes easily. It also caused outer loops to have a different "canonical" form from inner loops during analysis. Instead, we go into LCSSA form and preserve it through the loop pass manager run. Note that this has the same problem as LoopSimplify that prevents enabling its verification -- loop passes which run at the end of the loop pass manager and don't preserve these are valid, but the subsequent loop pass runs of outer loops that do preserve this pass trigger too much verification and fail because the inner loop no longer verifies. The other problem this exposed is that LICM was completely unable to handle LCSSA form. It didn't preserve it and it actually would give up on moving instructions in many cases when they were used by an LCSSA phi node. I've taught LICM to support detecting LCSSA-form PHI nodes and to hoist and sink around them. This may actually let LICM fire significantly more because we put everything into LCSSA form to rotate the loop before running LICM. =/ Now LICM should handle that fine and preserve it correctly. The down side is that LICM has to require LCSSA in order to preserve it. This is just a fact of life for LCSSA. It's entirely possible we should completely remove LCSSA from the optimizer. The test updates are essentially accomodating LCSSA phi nodes in the output of LICM, and the fact that we now completely sink every instruction in ashr-crash below the loop bodies prior to unrolling. With this change, LCSSA is computed only three times in the pass pipeline. One of them could be removed (and potentially a SCEV run and a separate LoopPassManager entirely!) if we had a LoopPass variant of InstCombine that ran InstCombine on the loop body but refused to combine away LCSSA PHI nodes. Currently, this also prevents loop unrolling from being in the same loop pass manager is rotate, LICM, and unswitch. There is one thing that I *really* don't like -- preserving LCSSA in LICM is quite expensive. We end up having to re-run LCSSA twice for some loops after LICM runs because LICM can undo LCSSA both in the current loop and the parent loop. I don't really see good solutions to this other than to completely move away from LCSSA and using tools like SSAUpdater instead. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200067 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Revert "Add Constant Hoisting Pass" (r200034)"Juergen Ributzka2014-01-25
| | | | | | | This reverts commit r200058 and adds the using directive for ARMTargetTransformInfo to silence two g++ overload warnings. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200062 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Add Constant Hoisting Pass" (r200034)Hans Wennborg2014-01-25
| | | | | | | | | | | | | | | This commit caused -Woverloaded-virtual warnings. The two new TargetTransformInfo::getIntImmCost functions were only added to the superclass, and to the X86 subclass. The other targets were not updated, and the warning highlighted this by pointing out that e.g. ARMTTI::getIntImmCost was hiding the two new getIntImmCost variants. We could pacify the warning by adding "using TargetTransformInfo::getIntImmCost" to the various subclasses, or turning it off, but I suspect that it's wrong to leave the functions unimplemnted in those targets. The default implementations return TCC_Free, which I don't think is right e.g. for ARM. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200058 91177308-0d34-0410-b5e6-96231b3b80d8
* Add Constant Hoisting PassJuergen Ributzka2014-01-24
| | | | | | | | Retry commit r200022 with a fix for the build bot errors. Constant expressions have (unlike instructions) module scope use lists and therefore may have users in different functions. The fix is to simply ignore these out-of-function uses. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200034 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Add Constant Hoisting Pass"Juergen Ributzka2014-01-24
| | | | | | This reverts commit r200022 to unbreak the build bots. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200024 91177308-0d34-0410-b5e6-96231b3b80d8
* Add Constant Hoisting PassJuergen Ributzka2014-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This pass identifies expensive constants to hoist and coalesces them to better prepare it for SelectionDAG-based code generation. This works around the limitations of the basic-block-at-a-time approach. First it scans all instructions for integer constants and calculates its cost. If the constant can be folded into the instruction (the cost is TCC_Free) or the cost is just a simple operation (TCC_BASIC), then we don't consider it expensive and leave it alone. This is the default behavior and the default implementation of getIntImmCost will always return TCC_Free. If the cost is more than TCC_BASIC, then the integer constant can't be folded into the instruction and it might be beneficial to hoist the constant. Similar constants are coalesced to reduce register pressure and materialization code. When a constant is hoisted, it is also hidden behind a bitcast to force it to be live-out of the basic block. Otherwise the constant would be just duplicated and each basic block would have its own copy in the SelectionDAG. The SelectionDAG recognizes such constants as opaque and doesn't perform certain transformations on them, which would create a new expensive constant. This optimization is only applied to integer constants in instructions and simple (this means not nested) constant cast experessions. For example: %0 = load i64* inttoptr (i64 big_constant to i64*) Reviewed by Eric git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200022 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-15 23:06:42 +0000