summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86] Tidied up shuffle decode function doxygen descriptionsSimon Pilgrim2016-04-082-30/+41
| | | | | | As discussed on D18441 - auto brief is used so we don't need /brief, we don't need to include the function name and added some missing descriptions. llvm-svn: 265785
* CXX_FAST_TLS calling convention: performance improvement for PPC64Chuang-Yu Cheng2016-04-088-3/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the same change on PPC64 as r255821 on AArch64. I have even borrowed his commit message. The access function has a short entry and a short exit, the initialization block is only run the first time. To improve the performance, we want to have a short frame at the entry and exit. We explicitly handle most of the CSRs via copies. Only the CSRs that are not handled via copies will be in CSR_SaveList. Frame lowering and prologue/epilogue insertion will generate a short frame in the entry and exit according to CSR_SaveList. The majority of the CSRs will be handled by register allcoator. Register allocator will try to spill and reload them in the initialization block. We add CSRsViaCopy, it will be explicitly handled during lowering. 1> we first set FunctionLoweringInfo->SplitCSR if conditions are met (the target supports it for the given machine function and the function has only return exits). We also call TLI->initializeSplitCSR to perform initialization. 2> we call TLI->insertCopiesSplitCSR to insert copies from CSRsViaCopy to virtual registers at beginning of the entry block and copies from virtual registers to CSRsViaCopy at beginning of the exit blocks. 3> we also need to make sure the explicit copies will not be eliminated. Author: Tom Jablin (tjablin) Reviewers: hfinkel kbarton cycheng http://reviews.llvm.org/D17533 llvm-svn: 265781
* [mips] Use range-based for loops. NFC.Vasileios Kalintiris2016-04-081-10/+16
| | | | llvm-svn: 265780
* [llvm-c] Expose LLVMContextGetDiagnostic{Handler,Context}Jeroen Ketema2016-04-081-1/+11
| | | | | | Differential Revision: http://reviews.llvm.org/D18820 llvm-svn: 265773
* [mips][microMIPS] Add CodeGen support for ADD, ADDIU*, ADDU* and DADD* ↵Zlatko Buljan2016-04-085-67/+188
| | | | | | | | instructions Differential Revision: http://reviews.llvm.org/D16454 llvm-svn: 265772
* Use std::fill to simplify some code. NFCCraig Topper2016-04-081-2/+3
| | | | llvm-svn: 265771
* Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"Duncan P. N. Exon Smith2016-04-082-23/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r265765, reapplying r265759 after changing a call from LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug intrinsic operand may no longer be pointing at a local. http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/ The previous coommit message follows: -- This is a partial re-commit -- maybe more of a re-implementation -- of r265631 (reverted in r265637). This makes RF_IgnoreMissingLocals behave (almost) consistently between the Value and the Metadata hierarchy. In particular: - MapValue returns nullptr or "metadata !{}" for missing locals in MetadataAsValue/LocalAsMetadata bridging paris, depending on the RF_IgnoreMissingLocals flag. - MapValue doesn't memoize LocalAsMetadata-related results. - MapMetadata no longer deals with LocalAsMetadata or RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but I realized during testing it would make the patch simpler with no loss of generality.) r265631 went too far, making both functions universally ignore RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt. Reassociate (and possibly other passes) don't currently maintain dominates-use invariants for metadata operands, resulting in IR like this: define void @foo(i32 %arg) { call void @llvm.some.intrinsic(metadata i32 %x) %x = add i32 1, i32 %arg } If the inliner chooses to inline @foo into another function, then RemapInstruction will call `MapValue(metadata i32 %x)` and assert that the return is not nullptr. I've filed PR27273 to add a Verifier check and fix the underlying problem in the optimization passes. As a workaround, return `!{}` instead of nullptr for unmapped LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match the behaviour of r265631. Original commit message: ValueMapper: Make LocalAsMetadata match function-local Values Start treating LocalAsMetadata similarly to function-local members of the Value hierarchy in MapValue and MapMetadata. - Don't memoize them. - Return nullptr if they are missing. This also cleans up ConstantAsMetadata to stop listening to the RF_IgnoreMissingLocals flag. llvm-svn: 265768
* Revert "ValueMapper: Treat LocalAsMetadata more like function-local Values"Duncan P. N. Exon Smith2016-04-082-64/+23
| | | | | | | | | | | | | This reverts commit r265759, since even this limited version breaks some bots: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3311 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/17696 This also reverts r265761 "ValueMapper: Unduplicate RF_NoModuleLevelChanges check, NFC", since I had trouble separating it from r265759. llvm-svn: 265765
* [TargetRegisterInfo] Re-apply r265734.Quentin Colombet2016-04-081-12/+5
| | | | | | | Original commit message: [TargetRegisterInfo] Refactor the code to use BitMaskClassIterator. llvm-svn: 265764
* Don't IPO over functions that can be de-refinedSanjoy Das2016-04-0823-58/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes PR26774. If you're aware of the issue, feel free to skip the "Motivation" section and jump directly to "This patch". Motivation: I define "refinement" as discarding behaviors from a program that the optimizer has license to discard. So transforming: ``` void f(unsigned x) { unsigned t = 5 / x; (void)t; } ``` to ``` void f(unsigned x) { } ``` is refinement, since the behavior went from "if x == 0 then undefined else nothing" to "nothing" (the optimizer has license to discard undefined behavior). Refinement is a fundamental aspect of many mid-level optimizations done by LLVM. For instance, transforming `x == (x + 1)` to `false` also involves refinement since the expression's value went from "if x is `undef` then { `true` or `false` } else { `false` }" to "`false`" (by definition, the optimizer has license to fold `undef` to any non-`undef` value). Unfortunately, refinement implies that the optimizer cannot assume that the implementation of a function it can see has all of the behavior an unoptimized or a differently optimized version of the same function can have. This is a problem for functions with comdat linkage, where a function can be replaced by an unoptimized or a differently optimized version of the same source level function. For instance, FunctionAttrs cannot assume a comdat function is actually `readnone` even if it does not have any loads or stores in it; since there may have been loads and stores in the "original function" that were refined out in the currently visible variant, and at the link step the linker may in fact choose an implementation with a load or a store. As an example, consider a function that does two atomic loads from the same memory location, and writes to memory only if the two values are not equal. The optimizer is allowed to refine this function by first CSE'ing the two loads, and the folding the comparision to always report that the two values are equal. Such a refined variant will look like it is `readonly`. However, the unoptimized version of the function can still write to memory (since the two loads //can// result in different values), and selecting the unoptimized version at link time will retroactively invalidate transforms we may have done under the assumption that the function does not write to memory. Note: this is not just a problem with atomics or with linking differently optimized object files. See PR26774 for more realistic examples that involved neither. This patch: This change introduces a new set of linkage types, predicated as `GlobalValue::mayBeDerefined` that returns true if the linkage type allows a function to be replaced by a differently optimized variant at link time. It then changes a set of IPO passes to bail out if they see such a function. Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18634 llvm-svn: 265762
* ValueMapper: Unduplicate RF_NoModuleLevelChanges check, NFCDuncan P. N. Exon Smith2016-04-081-8/+5
| | | | llvm-svn: 265761
* DwarfDebug: Support floating point constants in location lists.Adrian Prantl2016-04-083-18/+41
| | | | | | | | | | | | | | | | | | This patch closes a gap in the DWARF backend that caused LLVM to drop debug info for floating point variables that were constant for part of their scope. Floating point constants are emitted as one or more DW_OP_constu joined via DW_OP_piece. This fixes a regression caught by the LLDB testsuite that I introduced in r262247 when we stopped blindly expanding the range of singular DBG_VALUEs to span the entire scope and started to emit location lists with accurate ranges instead. Also deletes a now-impossible testcase (debug-loc-empty-entries). <rdar://problem/25448338> llvm-svn: 265760
* ValueMapper: Treat LocalAsMetadata more like function-local ValuesDuncan P. N. Exon Smith2016-04-082-16/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a partial re-commit -- maybe more of a re-implementation -- of r265631 (reverted in r265637). This makes RF_IgnoreMissingLocals behave (almost) consistently between the Value and the Metadata hierarchy. In particular: - MapValue returns nullptr or "metadata !{}" for missing locals in MetadataAsValue/LocalAsMetadata bridging paris, depending on the RF_IgnoreMissingLocals flag. - MapValue doesn't memoize LocalAsMetadata-related results. - MapMetadata no longer deals with LocalAsMetadata or RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but I realized during testing it would make the patch simpler with no loss of generality.) r265631 went too far, making both functions universally ignore RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt. Reassociate (and possibly other passes) don't currently maintain dominates-use invariants for metadata operands, resulting in IR like this: define void @foo(i32 %arg) { call void @llvm.some.intrinsic(metadata i32 %x) %x = add i32 1, i32 %arg } If the inliner chooses to inline @foo into another function, then RemapInstruction will call `MapValue(metadata i32 %x)` and assert that the return is not nullptr. I've filed PR27273 to add a Verifier check and fix the underlying problem in the optimization passes. As a workaround, return `!{}` instead of nullptr for unmapped LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match the behaviour of r265631. Original commit message: ValueMapper: Make LocalAsMetadata match function-local Values Start treating LocalAsMetadata similarly to function-local members of the Value hierarchy in MapValue and MapMetadata. - Don't memoize them. - Return nullptr if they are missing. This also cleans up ConstantAsMetadata to stop listening to the RF_IgnoreMissingLocals flag. llvm-svn: 265759
* Revert "[TargetRegisterInfo] Refactor the code to use BitMaskClassIterator."Quentin Colombet2016-04-081-5/+12
| | | | | | | | | | This reverts commit r265734. Looks like ASan is not happy about it. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/11741 Looking. llvm-svn: 265755
* [RegisterBankInfo] Make the debug output more compact.Quentin Colombet2016-04-081-1/+1
| | | | | | | Print the mask of the partial mapping as an hexadecimal instead of a binary value. llvm-svn: 265754
* [IR/Verifier] Fix (yet another) crash.Davide Italiano2016-04-081-8/+14
| | | | | | | We need to check that if we reference a retainedType from DICompileUnit we're actually referencing a DICompositeType. llvm-svn: 265752
* [RegBankSelect] Add a few debug statements.Quentin Colombet2016-04-071-0/+9
| | | | llvm-svn: 265749
* [RegisterBankInfo] Add print and dump method to the InstructionMappingQuentin Colombet2016-04-071-0/+16
| | | | | | helper class. llvm-svn: 265747
* [RegisterBankInfo] Add print and dump method to the ValueMapping helperQuentin Colombet2016-04-071-0/+16
| | | | | | class. llvm-svn: 265746
* [MachineInstr] Teach the print method about RegisterBank.Quentin Colombet2016-04-071-11/+10
| | | | | | | | Properly print either the register class or the register bank or a virtual register. Get rid of a few ifdefs in the process. llvm-svn: 265745
* [AArch64] Fix a typo in the register class to register bank mapping.Quentin Colombet2016-04-071-1/+1
| | | | | | For GPR family we want the GPR register bank, not FPR! llvm-svn: 265743
* [RegisterBankInfo] Strengthen getInstrMappingImpl.Quentin Colombet2016-04-071-14/+21
| | | | | | | Teach the target independent code how to take advantage of type information to get the mapping of an instruction. llvm-svn: 265739
* [RegisterBankInfo] Add a way to record what register bank covers aQuentin Colombet2016-04-071-1/+10
| | | | | | | | | | | | specific type. This will be used to find the default mapping of the instruction. Also, this information is recorded, instead of computed, because it is expensive from a type to know which register bank maps it. Indeed, we need to iterate through all the register classes of all the register banks to find the one that maps the given type. llvm-svn: 265736
* [RegisterBankInfo] Introduce getRegBankFromConstraints as an helperQuentin Colombet2016-04-071-20/+34
| | | | | | | | | | | method. NFC. The refactoring intends to make the code more readable and expose more features to potential derived classes. llvm-svn: 265735
* [TargetRegisterInfo] Refactor the code to use BitMaskClassIterator.Quentin Colombet2016-04-071-12/+5
| | | | llvm-svn: 265734
* [RegisterBankInfo] Refactor the code to use BitMaskClassIterator.Quentin Colombet2016-04-071-55/+24
| | | | llvm-svn: 265733
* Const correctness for BranchProbabilityInfo (NFC)Mehdi Amini2016-04-071-25/+26
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265731
* Rename parameter I to Index for WriteCombinedGlobalValueSummary() (NFC)Mehdi Amini2016-04-071-4/+4
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265729
* [RegBankSelect] Reuse RegisterBankInfo logic to get to the register bankQuentin Colombet2016-04-071-12/+2
| | | | | | | | | from a register. On top of duplicating the logic, it was buggy! It would assert on physical registers, since MachineRegisterInfo does not have any information regarding register classes/banks for them. llvm-svn: 265727
* Do not select EhPad BB in MachineBlockPlacement when there is regular BB to ↵Amaury Sechet2016-04-071-12/+66
| | | | | | | | | | | | | | | | | schedule Summary: EHPad BB are not entered the classic way and therefor do not need to be placed after their predecessors. This patch make sure EHPad BB are not chosen amongst successors to form chains, and are selected as last resort when selecting the best candidate. EHPad are scheduled in reverse probability order in order to have them flow into each others naturally. Reviewers: chandlerc, majnemer, rafael, MatzeB, escha, silvas Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17625 llvm-svn: 265726
* [AArch64] Get rid of some GlobalISel ifdefs.Quentin Colombet2016-04-071-3/+1
| | | | llvm-svn: 265725
* [AArch64] gcc does not like litteral without quotes even on preprocessor macros.Quentin Colombet2016-04-071-1/+1
| | | | llvm-svn: 265720
* [AArch64][CallLowering] Do not build the API if GlobalISel is not built.Quentin Colombet2016-04-072-14/+5
| | | | | | | This gets rid of some ifdefs and dummy implementations that were here just to fill the blanks. llvm-svn: 265719
* [GlobalISel] Add RegBankSelect hooks into the pass pipeline.Quentin Colombet2016-04-072-0/+14
| | | | | | | Now, RegBankSelect will happen after the IRTranslation and the target may optionally add additional passes in between. llvm-svn: 265716
* AMDGPU/SI: Implement atomic load/store for i32 and i64Jan Vesely2016-04-075-24/+111
| | | | | | | | | | Standard load/store instructions with GLC bit set. Reviewers: tstellardAMD, arsenm Differential Revision: http://reviews.llvm.org/D18760 llvm-svn: 265709
* AMDGPU/SI: Add latency for export instructionsTom Stellard2016-04-071-0/+1
| | | | | | | | | | Reviewers: arsenm, nhaehnle Subscribers: nhaehnle, arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D18599 llvm-svn: 265708
* [RegBankSelect] Initial implementation for non-optimized output.Quentin Colombet2016-04-071-3/+105
| | | | | | | | The pass walk through the machine function and assign the register banks using the default mapping. In other words, there is no attempt to reduce cross register copies. llvm-svn: 265707
* [RegisterBankInfo] Provide a target independent helper function to guessQuentin Colombet2016-04-071-41/+108
| | | | | | | | | | | | | the mapping of an instruction on register bank. For most instructions, it is possible to guess the mapping of the instruciton by using the encoding constraints. It remains instructions without encoding constraints. For copy-like instructions, we try to propagate the information we get from the other operands. Otherwise, the target has to give this information. llvm-svn: 265703
* [RegisterBankInfo] Change the signature of getSizeInBits to factor outQuentin Colombet2016-04-071-14/+23
| | | | | | the access to MRI and TRI. llvm-svn: 265701
* [RegisterBankInfo] Provide a default constructor for InstructionMappingQuentin Colombet2016-04-071-0/+1
| | | | | | | | | helper class. The default constructor creates invalid (isValid() == false) instances and may be used to communicate that a mapping was not found. llvm-svn: 265699
* [MachineRegisterInfo] Track register bank for virtual registers.Quentin Colombet2016-04-071-1/+6
| | | | | | | | | | | | | | | | | | | | A virtual register may have either a register bank or a register class. This is represented by a PointerUnion between the related classes. Typically, a virtual register went through the following states regarding register class and register bank: 1. Creation: None is set. Virtual registers are fully generic. 2. Register bank assignment: Register bank is set. Virtual registers live into a register bank, but we do not know the constraints they need to fulfil. 3. Instruction selection: Register class is set. Virtual registers are bound by encoding constraints. To map these states to GlobalISel, the IRTranslator implements #1, RegBankSelect #2, and Select #3. llvm-svn: 265696
* [RegisterBank] Rename RegisterBank::contains into RegisterBank::covers.Quentin Colombet2016-04-073-11/+11
| | | | llvm-svn: 265695
* [SystemZ] Fix build break from r265689Ulrich Weigand2016-04-071-2/+1
| | | | | | | Fix build error seen on some build bots due to: error: default label in switch which covers all enumeration values llvm-svn: 265693
* [X86]: Fix for PR27251.Kevin B. Smith2016-04-071-3/+18
| | | | | | Differential Revision: http://reviews.llvm.org/D18850 llvm-svn: 265690
* [SystemZ] Implement conditional returnsUlrich Weigand2016-04-076-84/+281
| | | | | | | | | | | | | | | | | | Return is now considered a predicable instruction, and is converted to a newly-added CondReturn (which maps to BCR to %r14) instruction by the if conversion pass. Also, fused compare-and-branch transform knows about conditional returns, emitting the proper fused instructions for them. This transform triggers on a *lot* of tests, hence the huge diffstat. The changes are mostly jX to br %r14 -> bXr %r14. Author: koriakin Differential Revision: http://reviews.llvm.org/D17339 llvm-svn: 265689
* [IR/Verifier] Merge two ifs into one. NFC.Davide Italiano2016-04-071-3/+1
| | | | llvm-svn: 265688
* [GVN] Address review comments for D18662Ulrich Weigand2016-04-071-9/+10
| | | | | | | | | | | As suggested by Chandler in his review comments for D18662, this follow-on patch renames some variables in GetLoadValueForLoad and CoerceAvailableValueToLoadType to hopefully make it more obvious which variables hold value sizes and which hold load/store sizes. No functional change intended. llvm-svn: 265687
* [GVN] Fix handling of sub-byte types in big-endian modeUlrich Weigand2016-04-071-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | When GVN wants to re-interpret an already available value in a smaller type, it needs to right-shift the value on big-endian systems to ensure the correct bytes are accessed. The shift value is the difference of the sizes of the two types. This is correct as long as both types occupy multiples of full bytes. However, when one of them is a sub-byte type like i1, this no longer holds true: we still need to shift, but only to access the correct *byte*. Accessing bits within the byte requires no shift in either endianness; e.g. an i1 resides in the least-significant bit of its containing byte on both big- and little-endian systems. Therefore, the appropriate shift value to be used is the difference of the *storage* sizes of the two types. This is already handled correctly in one place where such a shift takes place (GetStoreValueForLoad), but is incorrect in two other places: GetLoadValueForLoad and CoerceAvailableValueToLoadType. This patch changes both places to use the storage size as well. Differential Revision: http://reviews.llvm.org/D18662 llvm-svn: 265684
* [PPC] Enable transformations in PPCPassConfig::addIRPasses at O2Ehsan Amiri2016-04-071-1/+1
| | | | | | | | | | | | | | http://reviews.llvm.org/D18562 A large number of testcases has been modified so they pass after this test. One testcase is deleted, because I realized even after undoing the original change that was committed with this testcase, the testcase still passes. So I removed it. The change to one other testcase (test/CodeGen/PowerPC/pr25802.ll) is an arbitrary change to keep it passing. Given the original intention of the testcase, and the fact that fixing it will require some time to change the testcase, we concluded that this quick change will be enough. llvm-svn: 265683
* AMDGPU/SI: Add MachineBasicBlock parameter to SIInstrInfo::insertWaitStatesTom Stellard2016-04-074-6/+8
| | | | | | | | | | | | Summary: This makes it possible to insert nops at the end of blocks. Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D18549 llvm-svn: 265678
OpenPOWER on IntegriCloud