summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* Fix a bug in IfConversion.cpp.Cong Hou2015-12-011-3/+2
| | | | | | | | The bug is introduced in r254377 which failed some tests on ARM, where a new probability is assigned to a successor but the provided BB may not be a successor. llvm-svn: 254463
* use range-based for loops; NFCISanjay Patel2015-12-011-12/+6
| | | | llvm-svn: 254453
* don't repeat function/variable names in comments; NFCSanjay Patel2015-12-011-64/+57
| | | | llvm-svn: 254445
* fix typo; NFCSanjay Patel2015-12-011-1/+1
| | | | llvm-svn: 254442
* Fixed a failure in cost calculation for vector GEPElena Demikhovsky2015-12-011-8/+8
| | | | | | | | | Cost calculation for vector GEP failed with due to invalid cast to GEP index operand. The bug is fixed, added a test. http://reviews.llvm.org/D14976 llvm-svn: 254408
* Introduce new @llvm.get.dynamic.area.offset.i{32, 64} intrinsics.Yury Gribov2015-12-015-0/+34
| | | | | | | | | | | | | | | The @llvm.get.dynamic.area.offset.* intrinsic family is used to get the offset from native stack pointer to the address of the most recent dynamic alloca on the caller's stack. These intrinsics are intendend for use in combination with @llvm.stacksave and @llvm.restore to get a pointer to the most recent dynamic alloca. This is useful, for example, for AddressSanitizer's stack unpoisoning routines. Patch by Max Ostapenko. Differential Revision: http://reviews.llvm.org/D14983 llvm-svn: 254404
* Allow known and unknown probabilities coexist in MBB's successor list.Cong Hou2015-12-011-8/+17
| | | | | | | | | | Previously it is not allowed for each MBB to have successors with both known and unknown probabilities. However, this may be too strict as at this stage we could not always guarantee that. It is better to remove this restriction now, and I will work on validating MBB's successors' probabilities first (for example, check if the sum is approximate one). llvm-svn: 254402
* Replace all weight-based interfaces in MBB with probability-based ↵Cong Hou2015-12-018-303/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interfaces, and update all uses of old interfaces. (This is the second attempt to submit this patch. The first caused two assertion failures and was reverted. See https://llvm.org/bugs/show_bug.cgi?id=25687) The patch in http://reviews.llvm.org/D13745 is broken into four parts: 1. New interfaces without functional changes (http://reviews.llvm.org/D13908). 2. Use new interfaces in SelectionDAG, while in other passes treat probabilities as weights (http://reviews.llvm.org/D14361). 3. Use new interfaces in all other passes. 4. Remove old interfaces. This patch is 3+4 above. In this patch, MBB won't provide weight-based interfaces any more, which are totally replaced by probability-based ones. The interface addSuccessor() is redesigned so that the default probability is unknown. We allow unknown probabilities but don't allow using it together with known probabilities in successor list. That is to say, we either have a list of successors with all known probabilities, or all unknown probabilities. In the latter case, we assume each successor has 1/N probability where N is the number of successors. An assertion checks if the user is attempting to add a successor with the disallowed mixed use as stated above. This can help us catch many misuses. All uses of weight-based interfaces are now updated to use probability-based ones. Differential revision: http://reviews.llvm.org/D14973 llvm-svn: 254377
* RegisterPressure: If we do not collect dead defs the list must be emptyMatthias Braun2015-12-011-5/+1
| | | | llvm-svn: 254372
* RegisterPressure: Remove support for recede()/advance() at MBB boundariesMatthias Braun2015-12-011-18/+5
| | | | | | | Nobody was checking the returnvalue of recede()/advance() so we can simply replace this code with asserts. llvm-svn: 254371
* RegisterPressure: Split RegisterOperands analysis code from result object; NFCMatthias Braun2015-12-011-43/+60
| | | | | | | This is in preparation to expose the RegisterOperands class as RegisterPressure API. llvm-svn: 254368
* Revert r254348: "Replace all weight-based interfaces in MBB with ↵Hans Wennborg2015-12-018-171/+301
| | | | | | | | | | probability-based interfaces, and update all uses of old interfaces." and the follow-up r254356: "Fix a bug in MachineBlockPlacement that may cause assertion failure during BranchProbability construction." Asserts were firing in Chromium builds. See PR25687. llvm-svn: 254366
* Fix a bug in MachineBlockPlacement that may cause assertion failure during ↵Cong Hou2015-12-011-3/+7
| | | | | | | | BranchProbability construction. The root cause is the rounding behavior in BranchProbability construction. We may consider to use truncation instead in the future. llvm-svn: 254356
* Extend debug info for function parameters in SDAG.Evgeniy Stepanov2015-12-011-16/+11
| | | | | | | | | | | | | SDAG currently can emit debug location for function parameters when an llvm.dbg.declare points to either a function argument SSA temp, or to an AllocaInst. This change extends this logic by adding a fallback case when neither of the above is true. This is required for SafeStack, which may copy the contents of a byval function argument into something that is not an alloca, and then describe the target as the new location of the said argument. llvm-svn: 254352
* Replace all weight-based interfaces in MBB with probability-based ↵Cong Hou2015-12-018-301/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interfaces, and update all uses of old interfaces. The patch in http://reviews.llvm.org/D13745 is broken into four parts: 1. New interfaces without functional changes (http://reviews.llvm.org/D13908). 2. Use new interfaces in SelectionDAG, while in other passes treat probabilities as weights (http://reviews.llvm.org/D14361). 3. Use new interfaces in all other passes. 4. Remove old interfaces. This patch is 3+4 above. In this patch, MBB won't provide weight-based interfaces any more, which are totally replaced by probability-based ones. The interface addSuccessor() is redesigned so that the default probability is unknown. We allow unknown probabilities but don't allow using it together with known probabilities in successor list. That is to say, we either have a list of successors with all known probabilities, or all unknown probabilities. In the latter case, we assume each successor has 1/N probability where N is the number of successors. An assertion checks if the user is attempting to add a successor with the disallowed mixed use as stated above. This can help us catch many misuses. All uses of weight-based interfaces are now updated to use probability-based ones. Differential revision: http://reviews.llvm.org/D14973 llvm-svn: 254348
* Have 'optnone' respect the -fast-isel=false option.Paul Robinson2015-11-302-4/+9
| | | | | | | | This is primarily useful for debugging optnone v. ISel issues. Differential Revision: http://reviews.llvm.org/D14792 llvm-svn: 254335
* Use a lambda instead of std::bind and std::mem_fn I introduced in r254242. NFCCraig Topper2015-11-291-2/+3
| | | | llvm-svn: 254260
* [SelectionDAG] Use std::any_of instead of a manually coded loop. NFCCraig Topper2015-11-291-8/+4
| | | | llvm-svn: 254242
* [Stack realignment] Handling of aligned allocas.Jonas Paulsson2015-11-281-13/+15
| | | | | | | | | | | | | | | | | | | | This patch implements dynamic realignment of stack objects for targets with a non-realigned stack pointer. Behaviour in FunctionLoweringInfo is changed so that for a target that has StackRealignable set to false, over-aligned static allocas are considered to be variable-sized objects and are handled with DYNAMIC_STACKALLOC nodes. It would be good to group aligned allocas into a single big alloca as an optimization, but this is yet todo. SystemZ benefits from this, due to its stack frame layout. New tests SystemZ/alloca-03.ll for aligned allocas, and SystemZ/alloca-04.ll for "no-realign-stack" attribute on functions. Review and help from Ulrich Weigand and Hal Finkel. llvm-svn: 254227
* Expose isXxxConstant() functions from SelectionDAGNodes.h (NFC)Artyom Skrobov2015-11-252-20/+20
| | | | | | | | | | | | | | Summary: Many target lowerings copy-paste the code to test SDValues for known constants. This code can instead be shared in SelectionDAG.cpp, and reused in the targets. Reviewers: MatzeB, andreadb, tstellarAMD Subscribers: arsenm, jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D14945 llvm-svn: 254085
* Fix some places where we were assuming that memory type had been legalizedEric Christopher2015-11-252-3/+2
| | | | | | | | | | to a simple type when lowering a truncating store of a vector type. In this case for an EVT we'll return Expand as we should in all of the cases anyhow. The testcase triggered at the one in VectorLegalizer::LegalizeOp, inspection found the rest. llvm-svn: 254061
* LiveVariables should not clobber MachineOperand::IsDead, ::IsKill on ↵Matthias Braun2015-11-241-2/+6
| | | | | | | | | | reserved physical registers Patch by Nick Johnson <Nicholas.Paul.Johnson@deshawresearch.com> Differential Revision: http://reviews.llvm.org/D14875 llvm-svn: 254012
* Let SelectionDAG start to use probability-based interface to add successors.Cong Hou2015-11-245-217/+248
| | | | | | | | | | | | | | | | | | | | | | | | The patch in http://reviews.llvm.org/D13745 is broken into four parts: 1. New interfaces without functional changes. 2. Use new interfaces in SelectionDAG, while in other passes treat probabilities as weights. 3. Use new interfaces in all other passes. 4. Remove old interfaces. This the second patch above. In this patch SelectionDAG starts to use probability-based interfaces in MBB to add successors but other MC passes are still using weight-based interfaces. Therefore, we need to maintain correct weight list in MBB even when probability-based interfaces are used. This is done by updating weight list in probability-based interfaces by treating the numerator of probabilities as weights. This change affects many test cases that check successor weight values. I will update those test cases once this patch looks good to you. Differential revision: http://reviews.llvm.org/D14361 llvm-svn: 253965
* [DIE] Make DIE.h NDEBUG conditional-free.Davide Italiano2015-11-241-26/+18
| | | | | | Switch dump()/print() method definitions to LLVM_DUMP_METHOD instead. llvm-svn: 253945
* [WinEH] Fix problem where CodeGenPrepare incorrectly sinks a bitcast into an ↵Andrew Kaylor2015-11-231-0/+6
| | | | | | | | EH pad. Differential Revision: http://reviews.llvm.org/D14842 llvm-svn: 253902
* Remove duplicate getValueType() calls. NFCI.Simon Pilgrim2015-11-221-2/+2
| | | | llvm-svn: 253823
* Avoid dependency between TableGen and CodeGenKrzysztof Parzyszek2015-11-221-0/+27
| | | | | | | | Duplicate a few common definitions between DFAPacketizer.cpp and DFAPacketizerEmitter.cpp to avoid including files from CodeGen in TableGen. llvm-svn: 253820
* Hexagon V60/HVX DFA scheduler supportKrzysztof Parzyszek2015-11-211-9/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extended DFA tablegen to: - added "-debug-only dfa-emitter" support to llvm-tblgen - defined CVI_PIPE* resources for the V60 vector coprocessor - allow specification of multiple required resources - supports ANDs of ORs - e.g. [SLOT2, SLOT3], [CVI_MPY0, CVI_MPY1] means: (SLOT2 OR SLOT3) AND (CVI_MPY0 OR CVI_MPY1) - added support for combo resources - allows specifying ORs of ANDs - e.g. [CVI_XLSHF, CVI_MPY01] means: (CVI_XLANE AND CVI_SHIFT) OR (CVI_MPY0 AND CVI_MPY1) - increased DFA input size from 32-bit to 64-bit - allows for a maximum of 4 AND'ed terms of 16 resources - supported expressions now include: expression => term [AND term] [AND term] [AND term] term => resource [OR resource]* resource => one_resource | combo_resource combo_resource => (one_resource [AND one_resource]*) Author: Dan Palermo <dpalermo@codeaurora.org> kparzysz: Verified AMDGPU codegen to be unchanged on all llc tests, except those dealing with instruction encodings. Reapply the previous patch, this time without circular dependencies. llvm-svn: 253793
* Revert r253790: it breaks all builds for some reason.Krzysztof Parzyszek2015-11-211-30/+9
| | | | llvm-svn: 253791
* Hexagon V60/HVX DFA scheduler supportKrzysztof Parzyszek2015-11-211-9/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extended DFA tablegen to: - added "-debug-only dfa-emitter" support to llvm-tblgen - defined CVI_PIPE* resources for the V60 vector coprocessor - allow specification of multiple required resources - supports ANDs of ORs - e.g. [SLOT2, SLOT3], [CVI_MPY0, CVI_MPY1] means: (SLOT2 OR SLOT3) AND (CVI_MPY0 OR CVI_MPY1) - added support for combo resources - allows specifying ORs of ANDs - e.g. [CVI_XLSHF, CVI_MPY01] means: (CVI_XLANE AND CVI_SHIFT) OR (CVI_MPY0 AND CVI_MPY1) - increased DFA input size from 32-bit to 64-bit - allows for a maximum of 4 AND'ed terms of 16 resources - supported expressions now include: expression => term [AND term] [AND term] [AND term] term => resource [OR resource]* resource => one_resource | combo_resource combo_resource => (one_resource [AND one_resource]*) Author: Dan Palermo <dpalermo@codeaurora.org> kparzysz: Verified AMDGPU codegen to be unchanged on all llc tests, except those dealing with instruction encodings. llvm-svn: 253790
* [DAGCombiner] Bugfix for lost chain depenedency.Jonas Paulsson2015-11-211-13/+7
| | | | | | | | | | | | | | When MergeConsecutiveStores() combines two loads and two stores into wider loads and stores, the chain users of both of the original loads must be transfered to the new load, because it may be that a chain user only depends on one of the loads. New test case: test/CodeGen/SystemZ/dag-combine-01.ll Reviewed by James Y Knight. Bugzilla: https://llvm.org/bugs/show_bug.cgi?id=25310#c6 llvm-svn: 253779
* [CodeGenPrepare] Create more extloads and fewer andsGeoff Berry2015-11-201-1/+190
| | | | | | | | | | | | | | | Summary: Add and instructions immediately after loads that only have their low bits used, assuming that the (and (load x) c) will be matched as a extload and the ands/truncs fed by the extload will be removed by isel. Reviewers: mcrosier, qcolombet, ab Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14584 llvm-svn: 253722
* [ShrinkWrap] Teach ShrinkWrap to handle targets requiring a register scavenger.Arnaud A. de Grandmaison2015-11-201-15/+22
| | | | | | | | The included test only checks for a compiler crash for now. Several people are facing this issue, so we first resolve the crash, and will increase shrinkwrap's coverage later in a follow-up patch. llvm-svn: 253718
* Partially revert r253662: some unrelated work was accidentally committed ↵Daniel Sanders2015-11-201-1/+0
| | | | | | | | with it. Sorry. llvm-svn: 253663
* Revert the revert 253497 and 253539 - These commits aren't the cause of the ↵Daniel Sanders2015-11-201-0/+1
| | | | | | | | clang-cmake-mips failures. Sorry for the noise. llvm-svn: 253662
* [LTO] Add option to emit assembly from LTOCodeGeneratorTobias Edler von Koch2015-11-191-7/+8
| | | | | | | | | | This adds a new API, LTOCodeGenerator::setFileType, to choose the output file format for LTO CodeGen. A corresponding change to use this new API from llvm-lto and a test case is coming in a separate commit. Differential Revision: http://reviews.llvm.org/D14554 llvm-svn: 253622
* [WinEH] Disable most forms of demotionReid Kleckner2015-11-191-117/+5
| | | | | | | | | | Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
* Expand subregisters in MachineFrameInfo::getPristineRegsKrzysztof Parzyszek2015-11-191-4/+3
| | | | | | http://reviews.llvm.org/D14719 llvm-svn: 253600
* [CGP] despeculate expensive cttz/ctlz intrinsicsSanjay Patel2015-11-191-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is another step towards allowing SimplifyCFG to speculate harder, but then have CGP clean things up if the target doesn't like it. Previous patches in this series: http://reviews.llvm.org/D12882 http://reviews.llvm.org/D13297 D13297 should catch most expensive ops, but speculation of cttz/ctlz requires special handling because of weirdness in the intrinsic definition for handling a zero input (that definition can probably be blamed on x86). For example, if we have the usual speculated-by-select expensive op pattern like this: %tobool = icmp eq i64 %A, 0 %0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true %cond = select i1 %tobool, i64 64, i64 %0 ret i64 %cond There's an instcombine that will turn it into: %0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 false) ; is_zero_undef == false This CGP patch is looking for that case and despeculating it back into: entry: %tobool = icmp eq i64 %A, 0 br i1 %tobool, label %cond.end, label %cond.true cond.true: %0 = tail call i64 @llvm.cttz.i64(i64 %A, i1 true) ; is_zero_undef == true br label %cond.end cond.end: %cond = phi i64 [ %0, %cond.true ], [ 64, %entry ] ret i64 %cond This unfortunately may lead to poorer codegen (see the changes in the existing x86 test), but if we increase speculation in SimplifyCFG (the next step in this patch series), then we should avoid those kinds of cases in the first place. The need for this patch was originally mentioned here: http://reviews.llvm.org/D7506 with follow-up here: http://reviews.llvm.org/D7554 Differential Revision: http://reviews.llvm.org/D14630 llvm-svn: 253573
* X86: More efficient legalization of wide integer comparesHans Wennborg2015-11-195-1/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular, this makes the code for 64-bit compares on 32-bit targets much more efficient. Example: define i32 @test_slt(i64 %a, i64 %b) { entry: %cmp = icmp slt i64 %a, %b br i1 %cmp, label %bb1, label %bb2 bb1: ret i32 1 bb2: ret i32 2 } Before this patch: test_slt: movl 4(%esp), %eax movl 8(%esp), %ecx cmpl 12(%esp), %eax setae %al cmpl 16(%esp), %ecx setge %cl je .LBB2_2 movb %cl, %al .LBB2_2: testb %al, %al jne .LBB2_4 movl $1, %eax retl .LBB2_4: movl $2, %eax retl After this patch: test_slt: movl 4(%esp), %eax movl 8(%esp), %ecx cmpl 12(%esp), %eax sbbl 16(%esp), %ecx jge .LBB1_2 movl $1, %eax retl .LBB1_2: movl $2, %eax retl Differential Revision: http://reviews.llvm.org/D14496 llvm-svn: 253572
* Revert "Change memcpy/memset/memmove to have dest and source alignments."Pete Cooper2015-11-192-36/+32
| | | | | | | | | | This reverts commit r253511. This likely broke the bots in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253543
* Change memcpy/memset/memmove to have dest and source alignments.Pete Cooper2015-11-182-32/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html These intrinsics currently have an explicit alignment argument which is required to be a constant integer. It represents the alignment of the source and dest, and so must be the minimum of those. This change allows source and dest to each have their own alignments by using the alignment attribute on their arguments. The alignment argument itself is removed. There are a few places in the code for which the code needs to be checked by an expert as to whether using only src/dest alignment is safe. For those places, they currently take the minimum of src/dest alignments which matches the current behaviour. For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 500, i32 8, i1 false) will now read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 8 %dest, i8* align 8 %src, i32 500, i1 false) For out of tree owners, I was able to strip alignment from calls using sed by replacing: (call.*llvm\.memset.*)i32\ [0-9]*\,\ i1 false\) with: $1i1 false) and similarly for memmove and memcpy. I then added back in alignment to test cases which needed it. A similar commit will be made to clang which actually has many differences in alignment as now IRBuilder can generate different source/dest alignments on calls. In IRBuilder itself, a new argument was added. Instead of calling: CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, /* isVolatile */ false) you now call CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, SrcAlign, /* isVolatile */ false) There is a temporary class (IntegerAlignment) which takes the source alignment and rejects implicit conversion from bool. This is to prevent isVolatile here from passing its default parameter to the source alignment. Note, changes in future can now be made to codegen. I didn't change anything here, but this change should enable better memcpy code sequences. Reviewed by Hal Finkel. llvm-svn: 253511
* [DAGCombiner] Vector constant folding for comparisonsSimon Pilgrim2015-11-181-6/+14
| | | | | | | | | | This patch adds support for vector constant folding of integer/float comparisons. This requires FoldConstantVectorArithmetic to support scalar constant operands (in this case ISD::CONDCASE). In future we should be able to support other scalar constant types as necessary (and possibly start calling FoldConstantVectorArithmetic for all node creations) Differential Revision: http://reviews.llvm.org/D14683 llvm-svn: 253504
* [PGO] Value profiling supportBetul Buyukkurt2015-11-181-1/+2
| | | | | | | | | This change introduces an instrumentation intrinsic instruction for value profiling purposes, the lowering of the instrumentation intrinsic and raw reader updates. The raw profile data files for llvm-profdata testing are updated. llvm-svn: 253484
* [SelectionDAGBuilder] Make sure DemoteReg ends up in right reg-class.Jonas Paulsson2015-11-181-1/+2
| | | | | | | | | | | | | | | | | The virtual register containing the address for returned value on stack should in the DAG be represented with a CopyFromReg node and not a Register node. Otherwise, InstrEmitter will not make sure that it ends up in the right register class for the target instruction. SystemZ needs this, becuause the reg class for address registers is a subset of the general 64 bit register class. test/SystemZ/CodeGen/args-07.ll and args-04.ll updated to run with -verify-machineinstrs. Reviewed by Hal Finkel. llvm-svn: 253461
* Stop producing .data.rel sections.Rafael Espindola2015-11-182-12/+5
| | | | | | | | | | | | | | | | | If a section is rw, it is irrelevant if the dynamic linker will write to it or not. It looks like llvm implemented this because gcc was doing it. It looks like gcc implemented this in the hope that it would put all the relocated items close together and speed up the dynamic linker. There are two problem with this: * It doesn't work. Both bfd and gold will map .data.rel to .data and concatenate the input sections in the order they are seen. * If we want a feature like that, it can be implemented directly in the linker since it knowns where the dynamic relocations are. llvm-svn: 253436
* Remove a redundant assertion in MachineBasicBlock.cpp. NFC.Cong Hou2015-11-181-1/+0
| | | | llvm-svn: 253426
* Remove redundant code in MachineBasicBlock.cpp. NFC.Cong Hou2015-11-181-28/+8
| | | | llvm-svn: 253425
* Improving edge probabilities computation when choosing the best successor in ↵Cong Hou2015-11-181-13/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | machine block placement. When looking for the best successor from the outer loop for a block belonging to an inner loop, the edge probability computation can be improved so that edges in the inner loop are ignored. For example, suppose we are building chains for the non-loop part of the following code, and looking for B1's best successor. Assume the true body is very hot, then B3 should be the best candidate. However, because of the existence of the back edge from B1 to B0, the probability from B1 to B3 can be very small, preventing B3 to be its successor. In this patch, when computing the probability of the edge from B1 to B3, the weight on the back edge B1->B0 is ignored, so that B1->B3 will have 100% probability. if (...) do { B0; ... // some branches B1; } while(...); else B2; B3; Differential revision: http://reviews.llvm.org/D10825 llvm-svn: 253414
* Generalize ownership/passing semantics to allow dsymutil to own ↵David Blaikie2015-11-181-12/+5
| | | | | | | | | | | | | abbreviations via unique_ptr While still allowing CodeGen/AsmPrinter in llvm to own them using a bump ptr allocator. (might be nice to replace the pointers there with something that at least automatically calls their dtors, if that's necessary/useful, rather than having it done explicitly (I think a typed BumpPtrAllocator already does this, or maybe a unique_ptr with a custom deleter, etc)) llvm-svn: 253409
OpenPOWER on IntegriCloud