summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Avoid emitting a DWARF type attribute for an ObjC property of typeEric Christopher2014-01-231-1/+2
| | | | | | | | void. Patch by Scott Talbot. llvm-svn: 199924
* Add a variable to track whether or not we've used a unique section,Eric Christopher2014-01-231-3/+5
| | | | | | | | | | | | e.g. linkonce, to TargetMachine and set it when we've done so for ELF targets currently. This involved making TargetMachine non-const in a TLOF use and propagating that change around - I'm open to other ideas. This will be used in a future commit to handle emitting debug information with ranges. llvm-svn: 199871
* Revert r162101 and replace it with a solution that works for targets where ↵Owen Anderson2014-01-222-7/+11
| | | | | | | | | | the pointer type is illegal. This is a horrible bit of code. We're calling a simplification routine *in the middle* of type legalization. We tell the simplification routine that it's running after legalization, but some of the types it will encounter will be illegal! The fix is only to invoke the simplification if the types in question were legal, so that none of its invariants will be violated. llvm-svn: 199847
* Fix inline assembly that switches between ARM and Thumb modesGreg Fitzgerald2014-01-221-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch restores the ARM mode if the user's inline assembly does not. In the object streamer, it ensures that instructions following the inline assembly are encoded correctly and that correct mapping symbols are emitted. For the asm streamer, it emits a .arm or .thumb directive. This patch does not ensure that the inline assembly contains the ADR instruction to switch modes at runtime. The problem we need to solve is code like this: int foo(int a, int b) { int r = a + b; asm volatile( ".align 2 \n" ".arm \n" "add r0,r0,r0 \n" : : "r"(r)); return r+1; } If we compile this function in thumb mode then the inline assembly will switch to arm mode. We need to make sure that we switch back to thumb mode after emitting the inline assembly or we will incorrectly encode the instructions that follow (i.e. the assembly instructions for return r+1). Based on patch by David Peixotto Change-Id: Ib57f6d2d78a22afad5de8693fba6230ff56ba48b llvm-svn: 199818
* AVX512: combining setcc and zext is wrong on AVX512Elena Demikhovsky2014-01-221-1/+4
| | | | | | because vector compare instruction puts result in mask register. llvm-svn: 199798
* MachineCopyPropagation has special logic for removing COPY instructions. It ↵James Molloy2014-01-221-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | will remove plain COPYs using eraseFromParent(), but if the COPY has imp-defs/imp-uses it will convert it to a KILL, to keep the imp-def around. This actually totally breaks and causes the machine verifier to cry in several cases, one of which being: %RAX<def> = COPY %RCX<kill> %ECX<def> = COPY %EAX<kill>, %RAX<imp-use,kill> These subregister copies are together identified as noops, so are both removed. However, the second one as it has an imp-use gets converted into a kill: %ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill> As the original COPY has been removed, the verifier goes into tears at the use of undefined EAX and RAX. There are several hacky solutions to this hacky problem (which is all to do with imp-use/def weirdnesses), but the least hacky I've come up with is to *always* remove COPYs by converting to KILLs. KILLs are no-ops to the code generator so the generated code doesn't change (which is why they were partially used in the first place), but using them also keeps the def/use and imp-def/imp-use chains alive: %RAX<def> = KILL %RCX<kill> %ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill> The patch passes all test cases including the ones that check the removal of MOVs in this circumstance, along with an extra test I added to check subregister behaviour (which made the machine verifier fall over before my patch). The patch also adds some DEBUG() statements because the file hadn't got any. llvm-svn: 199797
* Reformat a loop for basic hygeine. Self review.Andrew Trick2014-01-221-5/+5
| | | | llvm-svn: 199788
* Fix typoMatt Arsenault2014-01-221-1/+1
| | | | llvm-svn: 199784
* CodeGen: Stop treating vectors as aggregatesDuncan P. N. Exon Smith2014-01-211-1/+1
| | | | | | | | | Fix a crash in SjLjEHPrepare::lowerIncomingArguments caused by treating VectorType like an aggregate. It's first-class! <rdar://problem/15854596> llvm-svn: 199768
* Fix PR18572 - llc crash during GenericScheduler::initPolicy().Andrew Trick2014-01-211-4/+10
| | | | | | | Generalized the heuristic that looks at the (very rough) size of the register file before enabling regpressure tracking. llvm-svn: 199766
* Adding new LTO APIs to parse metadata nodes and extract linker options andYunzhong Gao2014-01-211-0/+18
| | | | | | | | dependent libraries from a bitcode module. Differential Revision: http://llvm-reviews.chandlerc.com/D2343 llvm-svn: 199759
* Checked return warning from coverityRenato Golin2014-01-211-2/+3
| | | | llvm-svn: 199716
* Update StackProtector when coloring merges stack slotsHal Finkel2014-01-202-0/+31
| | | | | | | | | | | | | | | | StackProtector keeps a ValueMap of alloca instructions to layout kind tags for use by PEI and other later passes. When stack coloring replaces one alloca with a bitcast to another one, the key replacement in this map does not work. Instead, provide an interface to manage this updating directly. This seems like an improvement over the old behavior, where the layout map would not get updated at all when the stack slots were merged. In practice, however, there is likely no observable difference because PEI only did anything special with 'large array' kinds, and if one large array is merged with another, than the replacement should already have been a large array. This is an attempt to unbreak the clang-x86_64-darwin11-RA builder. llvm-svn: 199684
* Allow SMUL_LOHI and UMUL_LOHI to be narrow to MUL on targets where MUL is ↵Owen Anderson2014-01-201-1/+1
| | | | | | Custom rather than Legal. Even if the target is doing some kind of expansion for MUL, it's pretty much guaranteed to be more efficent than whatever it does for SMUL_LOHI or UMUL_LOHI! llvm-svn: 199678
* Update IR when merging slots in stack coloringHal Finkel2014-01-201-12/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way that stack coloring updated MMOs when merging stack slots, while correct, is suboptimal, and is incompatible with the use of AA during instruction scheduling. The solution, which involves the use of const_cast (and more importantly, updating the IR from within an MI-level pass), obviously requires some explanation: When the stack coloring pass was originally committed, the code in ScheduleDAGInstrs::buildSchedGraph tracked possible alias sets by using GetUnderlyingObject, and all load/store and store/store memory control dependencies where added between SUs at the object level (where only one object, that returned by GetUnderlyingObject, was used to identify the object associated with each MMO). When stack coloring merged stack slots, it would replace MMOs derived from the remapped alloca with the alloca with which the remapped alloca was being replaced. Because ScheduleDAGInstrs only used single objects, and tracked alias sets at the object level, this was a fine solution. In r169744, (Andy and) I updated the code in ScheduleDAGInstrs to use GetUnderlyingObjects, and track alias sets using, potentially, multiple underlying objects for each MMO. This was done, primarily, to provide the ability to look through PHIs, and provide better scheduling for induction-variable-dependent loads and stores inside loops. At this point, the MMO-updating code in stack coloring became suboptimal, because it would clear the MMOs for (i.e. completely pessimize) all instructions for which r169744 might help in scheduling. Updating the IR directly is the simplest fix for this (and the one with, by far, the least compile-time impact), but others are possible (we could give each MMO a small vector of potential values, or make use of a remapping table, constructed from MFI, inside ScheduleDAGInstrs). Unfortunately, replacing all MMO values derived from the remapped alloca with the base replacement alloca fundamentally breaks our ability to use AA during instruction scheduling (which is critical to performance on some targets). The reason is that the original MMO might have had an offset (either constant or dynamic) from the base remapped alloca, and that offset is not present in the updated MMO. One possible way around this would be to use GetPointerBaseWithConstantOffset, and update not only the MMO's value, but also its offset based on the original offset. Unfortunately, this solution would only handle constant offsets, and for safety (because AA is not completely restricted to deducing relationships with constant offsets), we would need to clear all MMOs without constant offsets over the entire function. This would be an even worse pessimization than the current single-object restriction. Any other solution would involve passing around a vector of remapped allocas, and teaching AA to use it, introducing additional complexity and overhead into AA. Instead, when remapping an alloca, we replace all IR uses of that alloca as well (optionally inserting a bitcast as necessary). This is even more efficient that the old MMO-updating code in the stack coloring pass (because it removes the need to call GetUnderlyingObject on all MMO values), removes the single-object pessimization in the default configuration, and enables the correct use of AA during instruction scheduling (all without any additional overhead). LLVM now no longer miscompiles itself on x86_64 when using -enable-misched -enable-aa-sched-mi -misched-bottomup=0 -misched-topdown=0 -misched=shuffle! Fixed PR18497. Because the alloca replacement is now done at the IR level, unless the MMO directly refers to the remapped alloca, the change cannot be seen at the MI level. As a result, there is no good way to fix test/CodeGen/X86/pr14090.ll. llvm-svn: 199658
* Track multiple stores per object when using AA in ScheduleDAGInstrsHal Finkel2014-01-201-21/+38
| | | | | | | | | | | | | | | | | | | When using AA to break false chain dependencies, we need to track multiple stores per object in ScheduleDAGInstrs. Historically, we tracked potential alias chains at the object level, and so all loads of an object would retain dependencies on any store to that object. With AA, however, this is not sufficient: non-overlapping stores and loads to the same object all need to be tested for dependencies separately, we cannot only test all loads to an object against only the last store (see PR18497 for an explicit example). To mitigate any unwelcome compile-time impact when not using AA, only one store is kept in the list per object when not using AA. This, along with a stack coloring change to come shortly, will provide a test case, fix PR18497 (and allow LLVM to compile itself using -enable-aa-sched-mi on x86-64). llvm-svn: 199657
* Fix a DenseMap iterator invalidation bug causing lots of crashes whenChandler Carruth2014-01-201-31/+35
| | | | | | | | | | | | | | | | | | | type units were enabled. The crux of the issue is that the addDwarfTypeUnitType routine can end up being indirectly recursive. In this case, the reference into the dense map (TU) became invalid by the time we popped all the way back and used it to add the DIE type signature. Instead, use early return in the case where we can bypass the recursive step and creating a type unit. Then use the pointer to the new type unit to set up the DIE type signature in the case where we have to. I tried really hard to reduce a testcase for this, but it's really annoying. You have to get this to be mid-recursion when the densemap grows. Even if we got a test case for this today, it'd be very unlikely to continue exercising this pattern. llvm-svn: 199630
* Debug info (LTO): Move the creation of accessibility flags toAdrian Prantl2014-01-181-15/+16
| | | | | | | | | getOrCreateSubprogramDIE to avoid attributes being added twice when DIEs are merged. rdar://problem/15842330. llvm-svn: 199536
* Add an emitRawComment function and use it to simplify some uses of EmitRawText.Rafael Espindola2014-01-162-20/+10
| | | | llvm-svn: 199397
* ReMat: fix overly cavalier attitude to sub-register indicesTim Northover2014-01-161-24/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two attempted optimisations in reMaterializeTrivialDef, trying to avoid promoting the size of a register too much when rematerializing. Unfortunately, both appear to be flawed. First, we see if the original register would have worked, but this is inadequate. Consider: v1 = SOMETHING (v1 is QQ) v2:Q0 = COPY v1:Q1 (v1, v2 are QQ) ... uses of v2 In this case even though v2 *could* be used directly as the output of SOMETHING, this would set the wrong bits of the QQ register involved. The correct rematerialization must be: v2:Q0_Q1 = SOMETHING (v2 promoted to QQQ) ... uses of v2:Q1_Q2 For the second optimisation, if the correct remat is "v2:idx = SOMETHING" then we can't necessarily expect v2 itself to be valid for SOMETHING, but we do try to hunt for a class between v1 and v2 that works. Unfortunately, this is also wrong: v1 = SOMETHING (v1 is QQ) v2:Q0_Q1 = COPY v1 (v1 is QQ, v2 is QQQ) ... uses of v2 as a QQQ The canonical rematerialization here is "v2:Q0_Q1 = SOMETHING". However current logic would decide that v2 could be a QQ (no interest is taken in later uses). This patch, therefore, always accepts the widened register class without trying to be clever. Generally there is no penalty to this (e.g. in the common GR32 < GR64 case, expanding the width doesn't matter because it's not like you were going to do anything else with the high bits of a GR32 register). It can increase register pressure in cases like the ARM VFP regs though (multiple non-overlapping but equivalent subregisters). This situation can be spotted by the fact that both source and destination in the not-quite-coalesced pair have a sub-register index and rematerialisation is skipped in that situation. Unfortunately, no in-tree targets actually expose this as far as I can tell (there are so few isAsCheapAsAMove instructions for it to trigger on) so I've been unable to produce a test. It was exposed in our ARM64 SPEC tests though, and I will be adding a test there that we should be able to contribute soon(TM). rdar://problem/15775279 llvm-svn: 199376
* Use a slightly smaller hack.Rafael Espindola2014-01-161-2/+1
| | | | llvm-svn: 199363
* [DAGCombiner] Fix a wrong check in method SimplifyVBinOp.Andrea Di Biagio2014-01-151-2/+2
| | | | | | | | | | | | | | | | | | | This fixes a regression intruced by r199135. Revision 199135 tried to simplify part of the logic in method DAGCombiner::SimplifyVBinOp introducing calls to method BuildVectorSDNode::isConstant(). However, that revision wrongly changed the check performed by method SimplifyVBinOp to identify dag nodes that can be folded. Before revision 199135, that method only tried to simplify vector binary operations if both operands were build_vector of Constant/ConstantFP/Undef only. After revision 199135, method SimplifyVBinop tried to simplify also vector binary operations with only one constant operand. This fixes the problem restoring the old behavior of SimplifyVBinOp. llvm-svn: 199328
* WinCOFF: Transform IR expressions featuring __ImageBase into image relative ↵David Majnemer2014-01-151-0/+4
| | | | | | | | | | | | | relocations MSVC on x64 requires that we create image relative symbol references to refer to RTTI data. Seeing as how there is no way to explicitly make reference to a given relocation type in LLVM IR, pattern match expressions of the form &foo - &__ImageBase. Differential Revision: http://llvm-reviews.chandlerc.com/D2523 llvm-svn: 199312
* Make sure we emit a relocation to the debug_ranges section in theEric Christopher2014-01-152-3/+12
| | | | | | presence of CU ranges. llvm-svn: 199276
* Enable use of ranges for translation units in the presence ofEric Christopher2014-01-141-5/+7
| | | | | | | -ffunction-sections and update comments and TODOs about other places that we should enable this. llvm-svn: 199263
* Decouple dllexport/dllimport from linkageNico Rieck2014-01-141-2/+0
| | | | | | | | | | | | | | | | | | | Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199218
* Fix valgrind warning for gcc builds.Patrik Hagglund2014-01-141-5/+4
| | | | | | | | Sorry, I don't understand why the warning is generated (a gcc bug?). Anyhow, the change should improve readablity. No functionality change intended. llvm-svn: 199214
* Revert "Decouple dllexport/dllimport from linkage"Nico Rieck2014-01-141-0/+2
| | | | | | | | Revert this for now until I fix an issue in Clang with it. This reverts commit r199204. llvm-svn: 199207
* Decouple dllexport/dllimport from linkageNico Rieck2014-01-141-2/+0
| | | | | | | | | | | | | | | | | | | Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199204
* Always let value types influence register classes.Jakob Stoklund Olesen2014-01-141-4/+13
| | | | | | | | | | | | | | | | | | | | | When creating a virtual register for a def, the value type should be used to pick the register class. If we only use the register class constraint on the instruction, we might pick a too large register class. Some registers can store values of different sizes. For example, the x86 xmm registers can hold f32, f64, and 128-bit vectors. The three different value sizes are represented by register classes with identical register sets: FR32, FR64, and VR128. These register classes have different spill slot sizes, so it is important to use the right one. The register class constraint on an instruction doesn't necessarily care about the size of the value its defining. The value type determines that. This fixes a problem where InstrEmitter was picking 32-bit register classes for 64-bit values on SPARC. llvm-svn: 199187
* Make getTargetStreamer return a possibly null pointer.Rafael Espindola2014-01-141-1/+1
| | | | | | | | | This will allow it to be called from target independent parts of the main streamer that don't know if there is a registered target streamer or not. This in turn will allow targets to perform extra actions at specified points in the interface: add extra flags for some labels, extra work during finalization, etc. llvm-svn: 199174
* [DAG] Refactor ReassociateOps - no functional change intended.Juergen Ributzka2014-01-131-73/+44
| | | | llvm-svn: 199146
* [DAG] Teach DAG to also reassociate vector operationsJuergen Ributzka2014-01-132-16/+60
| | | | | | | | | | This commit teaches DAG to reassociate vector ops, which in turn enables constant folding of vector op chains that appear later on during custom lowering and DAG combine. Reviewed by Andrea Di Biagio llvm-svn: 199135
* Hide the pre-RA-sched= option.Andrew Trick2014-01-132-2/+2
| | | | | | | | | This is a very confusing option for a feature that will go away. -enable-misched is exposed instead to help triage issues with the new scheduler. llvm-svn: 199133
* [PM] Split DominatorTree into a concrete analysis result object whichChandler Carruth2014-01-134-9/+12
| | | | | | | | | | | | | | | | | | | | | | | can be used by both the new pass manager and the old. This removes it from any of the virtual mess of the pass interfaces and lets it derive cleanly from the DominatorTreeBase<> template. In turn, tons of boilerplate interface can be nuked and it turns into a very straightforward extension of the base DominatorTree interface. The old analysis pass is now a simple wrapper. The names and style of this split should match the split between CallGraph and CallGraphWrapperPass. All of the users of DominatorTree have been updated to match using many of the same tricks as with CallGraph. The goal is that the common type remains the resulting DominatorTree rather than the pass. This will make subsequent work toward the new pass manager significantly easier. Also in numerous places things became cleaner because I switched from re-running the pass (!!! mid way through some other passes run!!!) to directly recomputing the domtree. llvm-svn: 199104
* [PM] Pull the generic graph algorithms and data structures for dominatorChandler Carruth2014-01-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | trees into the Support library. These are all expressed in terms of the generic GraphTraits and CFG, with no reliance on any concrete IR types. Putting them in support clarifies that and makes the fact that the static analyzer in Clang uses them much more sane. When moving the Dominators.h file into the IR library I claimed that this was the right home for it but not something I planned to work on. Oops. So why am I doing this? It happens to be one step toward breaking the requirement that IR verification can only be performed from inside of a pass context, which completely blocks the implementation of verification for the new pass manager infrastructure. Fixing it will also allow removing the concept of the "preverify" step (WTF???) and allow the verifier to cleanly flag functions which fail verification in a way that precludes even computing dominance information. Currently, that results in a fatal error even when you ask the verifier to not fatally error. It's awesome like that. The yak shaving will continue... llvm-svn: 199095
* Revert "ReMat: fix overly cavalier attitude to sub-register indices"Tim Northover2014-01-131-4/+24
| | | | | | | | | | Very sorry, this was a premature patch that I still need to investigate and finish off (for some reason beyond me at the moment it doesn't actually fix the issue in all cases). This reverts commit r199091. llvm-svn: 199093
* ReMat: fix overly cavalier attitude to sub-register indicesTim Northover2014-01-131-24/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two attempted optimisations in reMaterializeTrivialDef, trying to avoid promoting the size of a register too much when rematerializing. Unfortunately, both appear to be flawed. First, we see if the original register would have worked, but this is inadequate. Consider: v1 = SOMETHING (v1 is QQ) v2:Q0 = COPY v1:Q1 (v1, v2 are QQ) ... uses of v2 In this case even though v2 *could* be used directly as the output of SOMETHING, this would set the wrong bits of the QQ register involved. The correct rematerialization must be: v2:Q0_Q1 = SOMETHING (v2 promoted to QQQ) ... uses of v2:Q1_Q2 For the second optimisation, if the correct remat is "v2:idx = SOMETHING" then we can't necessarily expect v2 itself to be valid for SOMETHING, but we do try to hunt for a class between v1 and v2 that works. Unfortunately, this is also wrong: v1 = SOMETHING (v1 is QQ) v2:Q0_Q1 = COPY v1 (v1 is QQ, v2 is QQQ) ... uses of v2 as a QQQ The canonical rematerialization here is "v2:Q0_Q1 = SOMETHING". However current logic would decide that v2 could be a QQ (no interest is taken in later uses). This patch, therefore, always accepts the widened register class without trying to be clever. Generally there is no penalty to this (e.g. in the common GR32 < GR64 case, expanding the width doesn't matter because it's not like you were going to do anything else with the high bits of a GR32 register). It can increase register pressure in cases like the ARM VFP regs though (multiple non-overlapping but equivalent subregisters). Hopefully this situation is rare enough that it won't matter. Unfortunately, no in-tree targets actually expose this as far as I can tell (there are so few isAsCheapAsAMove instructions for it to trigger on) so I've been unable to produce a test. It was exposed in our ARM64 SPEC tests though, and I will be adding a test there that we should be able to contribute soon(TM). llvm-svn: 199091
* [cleanup] Move the Dominators.h and Verifier.h headers into the IRChandler Carruth2014-01-135-6/+6
| | | | | | | | | | | | | | | | | | directory. These passes are already defined in the IR library, and it doesn't make any sense to have the headers in Analysis. Long term, I think there is going to be a much better way to divide these matters. The dominators code should be fully separated into the abstract graph algorithm and have that put in Support where it becomes obvious that evn Clang's CFGBlock's can use it. Then the verifier can manually construct dominance information from the Support-driven interface while the Analysis library can provide a pass which both caches, reconstructs, and supports a nice update API. But those are very long term, and so I don't want to leave the really confusing structure until that day arrives. llvm-svn: 199082
* Handle bundled terminators in isBlockOnlyReachableByFallthrough.Jakob Stoklund Olesen2014-01-121-7/+7
| | | | | | | | | | Targets like SPARC and MIPS have delay slots and normally bundle the delay slot instruction with the corresponding terminator. Teach isBlockOnlyReachableByFallthrough to find any MBB operands on bundled terminators so SPARC doesn't need to specialize this function. llvm-svn: 199061
* Fix non-deterministic SDNodeOrder-dependent codegenNico Rieck2014-01-122-1/+6
| | | | | | | Reset SelectionDAGBuilder's SDNodeOrder to ensure deterministic code generation. llvm-svn: 199050
* [PM] Simplify the interface exposed for IR printing passes.Chandler Carruth2014-01-122-5/+4
| | | | | | | | | | | | Nothing was using the ability of the pass to delete the raw_ostream it printed to, and nothing was trying to pass it a pointer to the raw_ostream. Also, the function variant had a different order of arguments from all of the others which was just really confusing. Now the interface accepts a reference, doesn't offer to delete it, and uses a consistent order. The implementation of the printing passes haven't been updated with this simplification, this is just the API switch. llvm-svn: 199044
* [PM] Rename the IR printing pass header to a more generic and correctChandler Carruth2014-01-122-2/+2
| | | | | | | | name to match the source file which I got earlier. Update the include sites. Also modernize the comments in the header to use the more recommended doxygen style. llvm-svn: 199041
* Fix 'ned' typo in doc commentAlp Toker2014-01-111-1/+1
| | | | | | Patch by Jasper Neumann! llvm-svn: 199007
* Revert r198979 - accidental commit.Eric Christopher2014-01-111-5/+5
| | | | llvm-svn: 198981
* Reformat.Eric Christopher2014-01-111-5/+3
| | | | llvm-svn: 198980
* Update function name and add some helpful comments.Eric Christopher2014-01-111-3/+4
| | | | llvm-svn: 198979
* Revert "Revert r198851, "Prototype of skeleton type units for fission""David Blaikie2014-01-103-4/+27
| | | | | | | | | This reverts commit r198865 which reverts r198851. ASan identified a use-of-uninitialized of the DwarfTypeUnit::Ty variable in skeleton type units. llvm-svn: 198908
* Revert r198851, "Prototype of skeleton type units for fission"NAKAMURA Takumi2014-01-093-26/+4
| | | | | | It caused undefined behavior. DwarfTypeUnit::Ty might not be initialized properly, I guess. llvm-svn: 198865
* Handle masked rotate amountsRichard Sandiford2014-01-091-16/+72
| | | | | | | | | | | | | | At the moment we expect rotates to have the form: (or (shl X, Y), (shr X, Z)) where Y == bitsize(X) - Z or Z == bitsize(X) - Y. This form means that the (or ...) is undefined for Y == 0 or Z == 0. This undefinedness can be avoided by using Y == (C * bitsize(X) - Z) & (bitsize(X) - 1) or Z == (C * bitsize(X) - Y) & (bitsize(X) - 1) for any integer C (including 0, the most natural choice). llvm-svn: 198861
OpenPOWER on IntegriCloud