summaryrefslogtreecommitdiffstats
path: root/llvm
Commit message (Collapse)AuthorAgeFilesLines
* Create a wrapper pass for BranchProbabilityInfo.Cong Hou2015-07-157-70/+100
| | | | | | | | This new wrapper pass is useful when we want to do branch probability analysis conditionally (e.g. only in PGO mode) but don't want to add one more pass dependence. http://reviews.llvm.org/D11241 llvm-svn: 242349
* Silence GCC -Wparenthesis warningDavid Majnemer2015-07-151-3/+2
| | | | llvm-svn: 242348
* For new archive member we only need to store the full path.Rafael Espindola2015-07-154-18/+13
| | | | | | | We were storing both the path and the file name, which was redundant and easy to get confused up with. llvm-svn: 242347
* [LoopUnswitch] Add an else clause to IsTrivialUnswitchCondition() when ↵Chen Li2015-07-151-1/+2
| | | | | | | | | | | | | | | | | checking HeaderTerm instruction type Summary: This is a trivial code change with no functionality effect. When LoopUnswitch determines trivial unswitch condition, it checks whether the loop header's terminator instruction is a branch instruction or switch instruction since trivial unswitch condition can only apply to these two instruction types. The current code does not fail the check directly on other instruction types, but check the nullness of LoopExitBB variable instead. The added else clause makes the check fail immediately on other instruction types and makes the code more obvious. Reviewers: reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11239 llvm-svn: 242345
* test-release.sh: Run both .o files through sed before comparing themHans Wennborg2015-07-151-3/+4
| | | | | | | | | | On some systems (e.g. Mac OS X), sed will add a newline to the end of the output if there wasn't one already. This would cause false cmp errors since the .o file from Phase 2 was passed through sed and the one from Phase 3 wasn't. Work around this by passing both through sed. llvm-svn: 242341
* TargetRegisterInfo: Provide a way to check assigned registers in ↵Matthias Braun2015-07-158-10/+19
| | | | | | | | | | getRegAllocationHints() Pass a const reference to LiveRegMatrix to getRegAllocationHints() because some targets can prodive better hints if they can test whether a physreg has been used for register allocation yet. llvm-svn: 242340
* MIR Serialization: Serialize references from the stack objects to named allocas.Alex Lorenz2015-07-156-13/+61
| | | | | | | | | This commit serializes the references to the named LLVM alloca instructions from the stack objects in the machine frame info. This commit adds a field 'Name' to the struct 'yaml::MachineStackObject'. This new field is used to store the name of the alloca instruction when the alloca is present and when it has a name. llvm-svn: 242339
* Add a "debugger tuning" concept that allows us to fine-tune how wePaul Robinson2015-07-154-11/+116
| | | | | | | | | | | emit debug info, according to the preferences of the different debuggers used on various targets. Darwin and FreeBSD default to tuning for LLDB; PS4 defaults to tuning for the SCE (Sony Computer Entertainment) debugger. All others default to GDB. Differential Revision: http://reviews.llvm.org/D8506 llvm-svn: 242338
* Fix mergefunc infinite loopJF Bastien2015-07-152-2/+46
| | | | | | | | | | | | | | | Self-referential constants containing references to a merged function no longer cause the MergeFunctions pass to infinite loop. Also adds a reproduction IR which would otherwise fail, which was isolated from a similar issue in Chromium. Author: jrkoenig Reviewers: nlewycky, jfb Subscribers: llvm-commits, nlewycky, jfb Differential Revision: http://reviews.llvm.org/D11208 llvm-svn: 242337
* Simplify a few uses of remove_filename by using parent_path instead.Rafael Espindola2015-07-153-7/+4
| | | | llvm-svn: 242334
* Switch the release script to build with CMake by default (PR21561)Hans Wennborg2015-07-151-48/+66
| | | | | | | | | | | | | | | | | | | | It retains the possibility to use the autoconf build with a command-line option ('-use-autoconf'), and uses that by default on Darwin since compiler-rt requires it on that platform. This commit also removes the "Release-64" flavour and related logic. The script would previously do two builds unless the '-no-64bit' flag was passed, but on my machine and from those I asked this always ended up producing two 64-bit builds, causing much confusion. It also removes the -build-triple option, which caused the --build= flag to get passed to ./configure. This was presumably intended for cross-compiling, but none of the release testers use it. If someone does want to pass it, they can use '-configure-flags --build=foo' instead. Differential Revision: http://reviews.llvm.org/D10715 llvm-svn: 242331
* Handle the error of trying to convert a regular archive to a thin one.Rafael Espindola2015-07-154-2/+31
| | | | | | While at it, test that we can add to a thin archive. llvm-svn: 242330
* Rename doFunction() in BFI to calculate() and change its parameters from ↵Cong Hou2015-07-153-12/+12
| | | | | | | | pointers to references. http://reviews.llvm.org/D11196 llvm-svn: 242322
* Analyze recursive PHI nodes in BasicAATobias Edler von Koch2015-07-152-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch allows phi nodes like %x = phi [ %incptr, ... ] [ %var, ... ] %incptr = getelementptr %x, 1 to be analyzed by BasicAliasAnalysis. In aliasPHI, we can detect incoming values that are recursive GEPs with a constant offset. Instead of trying to analyze a recursive GEP (and failing), we now ignore it and instead set the size of the memory referenced by the PHINode to UnknownSize. This represents all the possible memory locations the pointer represented by the PHINode could be advanced to by the GEP. For now, this new behavior is turned off by default to allow debugging of performance degradations seen with SPEC/x86 and Hexagon benchmarks. The flag -basicaa-recphi turns it on. Reviewers: hfinkel, sanjoy Subscribers: tobiasvk_caf, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D10368 llvm-svn: 242320
* Revert "Refactor optimizeUncoalescable logic"Bruno Cardoso Lopes2015-07-151-246/+127
| | | | | | | | | | Likely broke compilation on ARM: http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/13054 This reverts commit 0b7824464fbe3d3f386e2d4aef6a431422709e53. llvm-svn: 242311
* Revert "Look through PHIs to find additional register sources"Bruno Cardoso Lopes2015-07-154-378/+83
| | | | | | | | | | Likely broke compilation on ARM: http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/13054 This reverts commit 131ce4a838c081516cbfed039fc986b33e3979d6. llvm-svn: 242310
* Test commit.Cong Hou2015-07-151-1/+0
| | | | | | This is a test commit (one blank line deleted). llvm-svn: 242308
* Delete declared but not implemented functions.Rafael Espindola2015-07-151-2/+0
| | | | llvm-svn: 242304
* Debug Info: Add basic support for external types references.Adrian Prantl2015-07-159-3/+100
| | | | | | | | | | | | | | This is a necessary prerequisite for bootstrapping the emission of debug info inside modules. - Adds a FlagExternalTypeRef to DICompositeType. External types must have a unique identifier. - External type references are emitted using a forward declaration with a DW_AT_signature([DW_FORM_ref_sig8]) based on the UID. http://reviews.llvm.org/D9612 llvm-svn: 242302
* Add missing load/store flags to thumb2 instructions.Pete Cooper2015-07-152-2/+5
| | | | | | | | | | | | | These were the cause of a verifier error when building 7zip with -verify-machineinstrs. Running 'make check' with the verifier triggered the same error on the test here so i've updated the test to run the verifier on one of its runs instead of adding a new one. While looking at this code, there was a stale comment that these instructions were only used for disassembly. This probably used to be the case, but they are now used in the 'ARM load / store optimization pass' too. llvm-svn: 242300
* [PPC64LE] Fix vec_sld semantics for little endianBill Schmidt2015-07-151-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vec_sld interface provides access to the vsldoi instruction. Unlike most of the vec_* interfaces, we do not attempt to change the generated code for vec_sld based on the endian mode. It is too difficult to correctly infer the desired semantics because of different element types, and the corrected instruction sequence is expensive, involving loading a permute control vector and performing a generalized permute. For GCC, this was implemented as "Don't touch the vec_sld" implementation. When it came time for the LLVM implementation, I did the same thing. However, this was hasty and incorrect. In LLVM's version of altivec.h, vec_sld was previously defined in terms of the vec_perm interface. Because vec_perm semantics are adjusted for little endian, this means that leaving vec_sld untouched causes it to generate something different for LE than for BE. Not good. This back-end patch accompanies the changes to altivec.h that change vec_sld's behavior for little endian. Those changes mean that we see slightly different code in the back end when trying to recognize a VSLDOI instruction in isVSLDOIShuffleMask. In particular, a ShuffleKind of 1 (where the two inputs are identical) must now be treated the same way as a ShuffleKind of 2 (little endian with different inputs) when little endian mode is in force. This is because ShuffleKind of 1 is defined using big-endian numbering. This has a ripple effect on LowerBUILD_VECTOR, where we create our own internal VSLDOI instructions. Because these are a ShuffleKind of 1, they will now have their shift amounts subtracted from 16 when recognizing the shuffle mask. To avoid problems we have to subtract them from 16 again before creating the VSLDOI instructions. There are a couple of other uses of BuildVSLDOI, but these do not need to be modified because the shift amount is 8, which is unchanged when subtracted from 16. llvm-svn: 242296
* Look through PHIs to find additional register sourcesBruno Cardoso Lopes2015-07-154-83/+378
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Teaches the ValueTracker in the PeepholeOptimizer to look through PHI instructions. - Add findNextSourceAndRewritePHI method to lookup into multiple sources returnted by the ValueTracker and rewrite PHIs with new sources. With these changes we can find more register sources and rewrite more copies to allow coaslescing of bitcast instructions. Hence, we eliminate unnecessary VR64 <-> GR64 copies in x86, but it could be extended to other archs by marking "isBitcast" on target specific instructions. The x86 example follows: A: psllq %mm1, %mm0 movd %mm0, %r9 jmp C B: por %mm1, %mm0 movd %mm0, %r9 jmp C C: movd %r9, %mm0 pshufw $238, %mm0, %mm0 Becomes: A: psllq %mm1, %mm0 jmp C B: por %mm1, %mm0 jmp C C: pshufw $238, %mm0, %mm0 Differential Revision: http://reviews.llvm.org/D11197 rdar://problem/20404526 llvm-svn: 242295
* Refactor optimizeUncoalescable logicBruno Cardoso Lopes2015-07-151-127/+246
| | | | | | | | | | | | | | | - Create a new CopyRewriter for Uncoalescable copy-like instructions - Change the ValueTracker to return a ValueTrackerResult This makes optimizeUncoalescable looks more like optimizeCoalescable and use the CopyRewritter infrastructure. This is also the preparation for looking up into PHI nodes in the ValueTracker. Differential Revision: http://reviews.llvm.org/D11195 llvm-svn: 242294
* Expose setPersonalityFn to GoAndrew Wilkins2015-07-151-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add Value.SetPersonality to the Go bindings. The Go bindings' Builder.CreateLandingPad has been updated, removing the obsolete personality argument. Background The personality attribute was removed from LandingPadInst in r239940, and llvm::Function::setPersonalityFn introduced. There was no corresponding change to either the C API or Go bindings. The Go bindings were broken until r239940, but that change was just to ignore the personality argument. This broke llgo. Reviewers: majnemer, pcc Subscribers: deadalnix, llvm-commits, axw Differential Revision: http://reviews.llvm.org/D11116 llvm-svn: 242289
* [PPC] Disassemble little endian ppc instructions in the right byte orderBenjamin Kramer2015-07-152-8/+681
| | | | | | PR24122. The test is simply a byte swapped version of ppc64-encoding.txt. llvm-svn: 242288
* -Added API for retrieving the default FPU of a CPU from TargetParser.Alexandros Lamprineas2015-07-152-84/+96
| | | | | | | | -Implemented as a table lookup. Change-Id: Iaad0eaf4b29b06827e6700269496dc1ba20e9018 Phabricator: http://reviews.llvm.org/D11100 llvm-svn: 242284
* [PM/AA] Fix *numerous* serious bugs in GlobalsModRef found byChandler Carruth2015-07-151-22/+31
| | | | | | | | | | | | | | | | | | | | | | | | | inspection. While we want to handle calls specially in this code because they should have been modeled by the call graph analysis that precedes it, we should *not* be re-implementing the predicates for whether an instruction reads or writes memory. Those are well defined already. Notably, at least the following issues seem to be clearly missed before: - Ordered atomic loads can "write" to memory by causing writes from other threads to become visible. Similarly for ordered atomic stores. - AtomicRMW instructions quite obviously both read and write to memory. - AtomicCmpXchg instructions also read and write to memory. - Fences read and write to memory. - Invokes of intrinsics or memory allocation functions. I don't have any test cases, and I suspect this has never really come up in the real world. But there is no reason why it wouldn't, and it makes the code simpler to do this the right way. While here, I've tried to make the loops significantly simpler as well and added helpful comments as to what is going on. llvm-svn: 242281
* [SDAG] Optimize unordered comparison in soft-float mode (patch by Anton ↵Alexey Bataev2015-07-156-74/+189
| | | | | | | | | | | Nadolskiy) Current implementation handles unordered comparison poorly in soft-float mode. Consider (a ULE b) which is a <= b. It is lowered to (ledf2(a, b) <= 0 || unorddf2(a, b) != 0) (in general). We can do better job by lowering it to (__gtdf2(a, b) <= 0). Such replacement is true for other CMP's (ult, ugt, uge). In general, we just call same function as for ordered case but negate comparison against zero. Differential Revision: http://reviews.llvm.org/D10804 llvm-svn: 242280
* [PowerPC] Use the MachineCombiner to reassociate fadd/fmulHal Finkel2015-07-154-0/+491
| | | | | | | | | | | | | This is a direct port of the code from the X86 backend (r239486/r240361), which uses the MachineCombiner to reassociate (floating-point) adds/muls to increase ILP, to the PowerPC backend. The rationale is the same. There is a lot of copy-and-paste here between the X86 code and the PowerPC code, and we should extract at least some of this into CodeGen somewhere. However, I don't want to do that until this code is enhanced to handle FMAs as well. After that, we'll be in a better position to extract the common parts. llvm-svn: 242279
* [PowerPC] Extend physical register live range in PPCVSXFMAMutateHal Finkel2015-07-151-2/+15
| | | | | | | | | | | | | If the source of the copy that defines the addend is a physical register, then its existing live range may not extend to the FMA being mutated. Make sure we extend the live range of the register to meet the FMA because it will become its operand in this case. I don't have an independent test case, but it will be exposed by change to be committed shortly enabling the use of the machine combiner to do fadd/fmul reassociation, and will be covered by one of the associated regression tests. llvm-svn: 242278
* [MachineCombiner] Work with itinerariesHal Finkel2015-07-152-4/+15
| | | | | | | | | | | | MachineCombiner predicated its use of scheduling-based metrics on hasInstrSchedModel(), but useful conclusions can be drawn from pipeline itineraries as well. Almost all of the logic (except for resource tracking in preservesResourceLen) can be used if we have an itinerary, so enable it in that case as well. This will be used by the PowerPC backend in an upcoming commit. llvm-svn: 242277
* [AArch64] Fix problems in decoding generic MSR instructionsPetr Pavlu2015-07-152-0/+7
| | | | | | | | | Bitpatterns rejected by the decoder method of `MSR (immediate)` should be decoded as the `extended MSR (register)` instruction. Differential Revision: http://reviews.llvm.org/D7174 llvm-svn: 242276
* [PM/AA] Cleanup some loops to be range-based. NFC.Chandler Carruth2015-07-151-20/+19
| | | | llvm-svn: 242275
* [TableGen] Improve decoding options for non-orthogonal instructionsPetr Pavlu2015-07-157-34/+303
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When FixedLenDecoder matches an input bitpattern of form [01]+ with an instruction bitpattern of form [01?]+ (where 0/1 are static bits and ? are mixed/variable bits) it passes the input bitpattern to a specific instruction decoder method which then makes a final decision whether the bitpattern is a valid instruction or not. This means the decoder must handle all possible values of the variable bits which sometimes leads to opcode rewrites in the decoder method when the instructions are not fully orthogonal. The patch provides a way for the decoder method to say that when it returns Fail it does not necessarily mean the bitpattern is invalid, but rather that the bitpattern is definitely not an instruction that is recognized by the decoder method. The decoder can then try to match the input bitpattern with other possible instruction bitpatterns. For example, this allows to solve a situation on AArch64 where the `MSR (immediate)` instruction has form: 1101 0101 0000 0??? 0100 ???? ???1 1111 but not all values of the ? bits are allowed. The rejected values should be handled by the `extended MSR (register)` instruction: 1101 0101 000? ???? ???? ???? ???? ???? The decoder will first try to decode an input bitpattern that matches both bitpatterns as `MSR (immediate)` but currently this puts the decoder method of `MSR (immediate)` into a situation when it must be able to decode all possible values of the ? bits, i.e. it would need to rewrite the instruction to `MSR (register)` when it is not `MSR (immediate)`. The patch allows to specify that the decoder method cannot determine if the instruction is valid for all variable values. The decoder method can simply return Fail when it knows it is definitely not `MSR (immediate)`. The decoder will then backtrack the decoding and find that it can match the input bitpattern with the more generic `MSR (register)` bitpattern too. Differential Revision: http://reviews.llvm.org/D7174 llvm-svn: 242274
* [X86][SSE] Added i686/SSE2 vector shift tests.Simon Pilgrim2015-07-153-34/+987
| | | | | | We were only testing on x86-64, but we should be ensuring decent code gen of i64 shifts on 32-bit targets. llvm-svn: 242273
* AVX : Fix ISA disabling in case AVX512VL , some instructions should be ↵Igor Breger2015-07-153-30/+246
| | | | | | | | | | disabled only if AVX512BW present. Tests added. Differential Revision: http://reviews.llvm.org/D11122 llvm-svn: 242270
* Initial support for writing thin archives.Rafael Espindola2015-07-155-18/+45
| | | | llvm-svn: 242269
* Tidy-up test case from r242257.Michael Zolotukhin2015-07-151-5/+8
| | | | llvm-svn: 242268
* [vim] Update the syntax to mark REQUIRES lines and not talk aboutChandler Carruth2015-07-151-3/+3
| | | | | | | | | | | dejagnu. I wonder if it would be useful to handle FileCheck prefixes specially? Especially if we could get some error checking. Suggestions welcome. Patches more welcome as I have no idea what I'm doing with vim script.... llvm-svn: 242267
* [vim] Add the IR's comment prefix to the comments list. This allows vimChandler Carruth2015-07-151-0/+1
| | | | | | | | to intelligently wrap prose written in IR comment blocks. This has bothered me for roughly ever, and my fellow IRC denziens convinced me to fix it. llvm-svn: 242266
* Use enum instead of unsigned. NFC.Pete Cooper2015-07-152-2/+4
| | | | | | | | The unsigned opcode argument here was the result of BinaryOperator->getOpcode(). That returns a BinaryOps enum which is more accurate than passing around an unsigned. llvm-svn: 242265
* Use cast<> instead of dyn_cast to remove llvm_unreachable. NFC.Pete Cooper2015-07-151-4/+2
| | | | | | | | | | This code was checking if we are an ICmpInst or FCmpInst then throwing unreachable if we are neither. We must be one or the other, so use a cast on the FCmpInst case to ensure that we are that case. Then we can avoid having an unreachable but still catch an error if we ever had another subclass of CmpInst. llvm-svn: 242264
* Use another foreach loop. NFCPete Cooper2015-07-151-2/+1
| | | | llvm-svn: 242263
* Use getAnyExtOrTrunc helper instead of manually doing ext/trunc check. NFC.Pete Cooper2015-07-151-14/+5
| | | | | | | The code here was doing exactly what is already in getAnyExtOrTrunc(). Just use that method instead. llvm-svn: 242261
* Use getZExtOrTrunc helper instead of manually doing zext/trunc check. NFC.Pete Cooper2015-07-152-4/+2
| | | | | | | The code here was doing exactly what is already in getZExtOrTrunc(). Just use that method instead. llvm-svn: 242260
* [LoopUnrolling] Handle cast instructions.Michael Zolotukhin2015-07-152-0/+109
| | | | | | | | | During estimation of unrolling effect we should be able to propagate constants through casts. Differential Revision: http://reviews.llvm.org/D10207 llvm-svn: 242257
* Change conditional to assert. NFC.Pete Cooper2015-07-151-3/+2
| | | | | | | | This code was breaking from the case statement if the getStoreSizeInBits() value was not a multiple of 0. Given that the implementation returns getStoreSize() * 8, it can only be a multiple of 8. llvm-svn: 242255
* Use getStoreSize() instead of getStoreSizeInBits()/8. NFC.Pete Cooper2015-07-151-2/+1
| | | | | | | | The calls here were both to getStoreSizeInBits() which multiplies by 8. We then immediately divided by 8. Calling getStoreSize() returns the values we need without the extra arithmetic. llvm-svn: 242254
* Use a range loop.Rafael Espindola2015-07-141-4/+2
| | | | llvm-svn: 242250
* Use more foreach loops in SelectionDAG. NFCPete Cooper2015-07-144-42/+39
| | | | llvm-svn: 242249
OpenPOWER on IntegriCloud