summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* AMDGPU: Fix not moving users of s_bfe_i64 to VALUMatt Arsenault2015-08-261-0/+2
| | | | | | | This wouldn't propagate to users of the original BFE and would hit a verifier error. llvm-svn: 246078
* AMDGPU: Don't create intermediate SALU instructionsMatt Arsenault2015-08-262-27/+44
| | | | | | | | | | | | When splitting 64-bit operations, create the correct VALU instructions immediately. This was splitting things like s_or_b64 into the two s_or_b32s and then pushing the new instructions onto the worklist. There's no reason we need to do this intermediate step. llvm-svn: 246077
* SelectionDAGBuilder: Fix SPDescriptor not resetting GuardRegMatthias Braun2015-08-261-0/+1
| | | | | | | | This was causing problems when some functions use a GuardReg and some don't as can happen when mixing SelectionDAG and FastISel generated functions. llvm-svn: 246075
* FastISel: Avoid adding a successor block twice for degenerate IR.Matthias Braun2015-08-261-1/+5
| | | | | | | | This fixes http://llvm.org/PR24581 Differential Revision: http://reviews.llvm.org/D12350 llvm-svn: 246074
* Expose hasLiveCondCodeDef as a member function of the X86InstrInfo class. NFCAndrew Kaylor2015-08-262-1/+5
| | | | | | | | | This takes the existing static function hasLiveCondCodeDef and makes it a member function of the X86InstrInfo class. This is a useful utility function that an upcoming change would like to use. NFC. Patch by: Kevin B. Smith Differential Revision: http://reviews.llvm.org/D12371 llvm-svn: 246073
* Fix memory leak in sample profile pass.Diego Novillo2015-08-261-28/+23
| | | | | | | | | | | | | | | | The problem here were the function analyses invoked by the function pass manager from the new IPO pass. I looked at other IPO passes needing dominance information and the only one that requires it (partial inliner) does not use the standard dependency mechanism. This patch mimics what the partial inliner does to compute dominance, post-dominance and loop info. One thing I like about this approach is that I can delay the computation of all this until I actually need it. This should bring the ASAN buildbot back to green. If there's a better way to fix this, I'll do it in a follow-up patch. llvm-svn: 246066
* Revert "Fix LLVM C API for DataLayout"Mehdi Amini2015-08-261-8/+22
| | | | | | | | This reverts commit r246052. Third attempt, still unpleasant for some bots. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 246057
* AMDGPU/SI: Report SIFixSGPRLiveRanges changed functionMatt Arsenault2015-08-261-1/+4
| | | | llvm-svn: 246056
* Fix LLVM C API for DataLayoutMehdi Amini2015-08-261-22/+8
| | | | | | | | | | | | | | | | | | | | | | | | | We removed access to the DataLayout on the TargetMachine and deprecated the C API function LLVMGetTargetMachineData() in r243114. However the way I tried to be backward compatible was broken: I changed the wrapper of the TargetMachine to be a structure that includes the DataLayout as well. However the TargetMachine is also wrapped by the ExecutionEngine, in the more classic way. A client using the TargetMachine wrapped by the ExecutionEngine and trying to get the DataLayout would break. It seems tricky to solve the problem completely in the C API implementation. This patch tries to address this backward compatibility in a more lighter way in the C++ API. The C API is restored in its original state and the removed C++ API is reintroduced, but privately. The C API is friended to the TargetMachine and should be the only consumer for this API. Reviewers: ributzka Differential Revision: http://reviews.llvm.org/D12263 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 246052
* AMDGPU: Make sure to reserve super registersMatt Arsenault2015-08-262-16/+18
| | | | | | | | I think this could potentially have broken if one of the super registers were allocated that contain v254/v255. llvm-svn: 246051
* Revert "Fix LLVM C API for DataLayout"Mehdi Amini2015-08-261-8/+22
| | | | | | | | This reverts commit r246044. Build broken, still. It builds for me... From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 246049
* AMDGPU: Produce error on dynamic_stackallocMatt Arsenault2015-08-263-0/+19
| | | | llvm-svn: 246048
* [SimplifyLibCalls] Fix a typoDavid Majnemer2015-08-261-1/+1
| | | | | | | cbrt(sqrt(x)) calculates the sixth root, not the ninth root. cbrt(cbrt(x)) calculates the ninth root. llvm-svn: 246046
* Fix LLVM C API for DataLayoutMehdi Amini2015-08-261-22/+8
| | | | | | | | | | | | | | | | | | | | | | | | | We removed access to the DataLayout on the TargetMachine and deprecated the C API function LLVMGetTargetMachineData() in r243114. However the way I tried to be backward compatible was broken: I changed the wrapper of the TargetMachine to be a structure that includes the DataLayout as well. However the TargetMachine is also wrapped by the ExecutionEngine, in the more classic way. A client using the TargetMachine wrapped by the ExecutionEngine and trying to get the DataLayout would break. It seems tricky to solve the problem completely in the C API implementation. This patch tries to address this backward compatibility in a more lighter way in the C++ API. The C API is restored in its original state and the removed C++ API is reintroduced, but privately. The C API is friended to the TargetMachine and should be the only consumer for this API. Reviewers: ributzka Differential Revision: http://reviews.llvm.org/D12263 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 246044
* [SPARC] Fix stupid oversight in stack realignment support.James Y Knight2015-08-263-2/+37
| | | | | | | | | | | | | | | | | | | | If you're going to realign %sp to get object alignment properly (which the code does), and stack offsets and alignments are calculated going down from %fp (which they are), then the total stack size had better be a multiple of the alignment. LLVM did indeed ensure that. And then, after aligning, the sparc frame code added 96 (for sparcv8) to the frame size, making any requested alignment of 64-bytes or higher *guaranteed* to be misaligned. The test case added with r245668 even tests this exact scenario, and asserted the incorrect behavior, which I somehow failed to notice. D'oh. This change fixes the frame lowering code to align the stack size *after* adding the spill area, instead. Differential Revision: http://reviews.llvm.org/D12349 llvm-svn: 246042
* [llvm-mc] Ignore opcode size prefix in 64-bit CALL disassemblyVedant Kumar2015-08-261-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
* [AArch64] Remove a use-after-free when collecting stats.Chad Rosier2015-08-261-4/+4
| | | | | | | The call to mergePairedInsns() deletes MI, so the later use by isUnscaledLdSt() is referencing freed memory. llvm-svn: 246033
* [AArch64] Unify the integer min/max vector selection patterns with the ↵Silviu Baranga2015-08-262-52/+16
| | | | | | | | | | | | | | | | | | | | intrinsic ones Summary: This change lowers the aarch64 integer vector min/max intrinsic nodes to generic min/max nodes and replaces the intrinsic selection patterns with the generic ones. There should already be testing in place for this, so no further tests were added. Reviewers: jmolloy Subscribers: aemerson, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D12276 llvm-svn: 246030
* [SROA] Rip out all support for SSAUpdater in SROA.Chandler Carruth2015-08-261-198/+8
| | | | | | | | | | | | | This was only added to preserve the old ScalarRepl's use of SSAUpdater which was originally to avoid use of dominance frontiers. Now, we only need a domtree, and we'll need a domtree right after this pass as well and so it makes perfect sense to always and only use the dom-tree powered mem2reg. This was flag-flipper earlier and has stuck reasonably so I wanted to gut the now-dead code out of SROA before we waste more time with it. Among other things, this will make passmanager porting easier. llvm-svn: 246028
* Modernize with range-based for loops.Alex Rosenberg2015-08-261-21/+15
| | | | llvm-svn: 246018
* Reduce code duplication.Alex Rosenberg2015-08-261-12/+23
| | | | llvm-svn: 246017
* Trailing whitespaceAlex Rosenberg2015-08-261-1/+1
| | | | llvm-svn: 246016
* [MC] Split the layout part of MCAssembler::finish() into its own method. NFC.Frederic Riss2015-08-261-6/+9
| | | | | | | | | | Split a MCAssembler::layout() method out of MCAssembler::finish(). This allows running the MCSections layout separately from the streaming of the output file. This way if a client wants to use MC to generate section contents, but emit something different than the standard relocatable object files it is possible (llvm-dsymutil is such a client). llvm-svn: 246008
* [MC/MachO] Make some MachObjectWriter methods more generic. NFC.Frederic Riss2015-08-261-25/+30
| | | | | | | Hardcode less values in some mach-o header writing routines and pass them as argument. Doing so will allow reusing this code in llvm-dsymutil. llvm-svn: 246007
* Comparing operands should not require the same ValueIDJF Bastien2015-08-261-5/+2
| | | | | | | | | | | | | Summary: When comparing basic blocks, there is an additional check that two Value*'s should have the same ID, which interferes with merging equivalent constants of different kinds (such as a ConstantInt and a ConstantPointerNull in the included testcase). The cmpValues function already ensures that the two values in each function are the same, so removing this check should not cause incorrect merging. Also, the type comparison is redundant, based on reviewing the code and testing on the test suite and several large LTO bitcodes. Author: jrkoenig Reviewers: nlewycky, jfb, dschuff Subscribers: llvm-commits Differential revision: http://reviews.llvm.org/D12302 llvm-svn: 246001
* Expose more properties of llvm::fltSemanticsJF Bastien2015-08-261-0/+15
| | | | | | | | | | | Summary: Adds accessor functions for all the fields in llvm::fltSemantics. This will be used in MergeFunctions to order two APFloats with different semanatics. Author: jrkoenig Reviewers: jfb Subscribers: dschuff, llvm-commits Differential revision: http://reviews.llvm.org/D12253 llvm-svn: 245999
* FastISel: Use finishCondBranch() for ARM,Mips,PowerPC FastISelMatthias Braun2015-08-263-10/+5
| | | | | | Note that after this change branch probabilities are preserved now. llvm-svn: 245998
* FastISel: Factor out common code; NFC intendedMatthias Braun2015-08-263-69/+22
| | | | | | | | | This should be no functional change but for the record: For three cases in X86FastISel this will change the order in which the FalseMBB and TrueMBB of a conditional branch is addedd to the successor/predecessor lists. llvm-svn: 245997
* WebAssembly: add small FIXME for AsmPrinter.JF Bastien2015-08-261-0/+1
| | | | | | Suggested by @sunfish as a follow-up to r245982. llvm-svn: 245996
* Make variable argument intrinsics behave correctly in a Win64 CC function.Charles Davis2015-08-254-58/+77
| | | | | | | | | | | | | | | | Summary: This change makes the variable argument intrinsics, `llvm.va_start` and `llvm.va_copy`, and the `va_arg` instruction behave as they do on Windows inside a `CallingConv::X86_64_Win64` function. It's needed for a Clang patch I have to add support for GCC's `__builtin_ms_va_list` constructs. Reviewers: nadav, asl, eugenis CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1622 llvm-svn: 245990
* WebAssembly: assert that there aren't any constant poolsJF Bastien2015-08-251-0/+7
| | | | | | WebAssembly will either use globals or immediates, since it's a virtual ISA. llvm-svn: 245989
* WebAssembly: emit `(func (param t) (result t))` s-expressionsJF Bastien2015-08-251-0/+61
| | | | | | | | | | | | Summary: Match spec format: https://github.com/WebAssembly/spec/blob/master/ml-proto/test/fac.wasm Reviewers: sunfish Subscribers: llvm-commits, jfb Differential Revision: http://reviews.llvm.org/D12307 llvm-svn: 245986
* WebAssembly: comment out .globl when printing textual assemblyJF Bastien2015-08-251-1/+4
| | | | | | Do the same for .weak (not implemented for now, but may as well to it). Update comment string to two semicolons. llvm-svn: 245982
* [msan] Precise instrumentation for icmp sgt %x, -1.Evgeniy Stepanov2015-08-251-15/+20
| | | | | | | | | | Extend signed relational comparison instrumentation with a special case for comparisons with -1. This fixes an MSan false positive when such comparison is used as a sign bit test. https://llvm.org/bugs/show_bug.cgi?id=24561 llvm-svn: 245980
* MachineBasicBlock: Use MCPhysReg instead of unsigned in livein APIMatthias Braun2015-08-251-5/+4
| | | | | | | This is friendlier to the readers as it makes it clear that the API is not meant for vregs but just for physregs. llvm-svn: 245977
* Remove the final bit test during lowering switch statement if all cases in ↵Cong Hou2015-08-253-21/+39
| | | | | | | | | | bit test cover a contiguous range. When lowering switch statement, if bit tests are used then LLVM will always generates a jump to the default statement in the last bit test. However, this is not necessary when all cases in bit tests cover a contiguous range. This is because when generating the bit tests header MBB, there is a range check that guarantees cases in bit tests won't go outside of [low, high], where low and high are minimum and maximum case values in the bit tests. This patch checks if this is the case and then doesn't emit jump to default statement and hence saves a bit test and a branch. Differential Revision: http://reviews.llvm.org/D12249 llvm-svn: 245976
* [MachO] Move trivial accessors to header.Davide Italiano2015-08-251-18/+0
| | | | | | Requested by: Jim Grosbach. llvm-svn: 245963
* Update libdeps in LLVMipo and LLVMScalarOpts, corresponding to r245940.NAKAMURA Takumi2015-08-252-2/+2
| | | | llvm-svn: 245957
* Fix dependencies/shared library buildMatthias Braun2015-08-251-1/+1
| | | | llvm-svn: 245955
* Fix dropped conditional in cleanup in r245752David Blaikie2015-08-251-3/+4
| | | | | | Code review feedback by Charlie Turner. llvm-svn: 245954
* The patch replace the overflow check in loop vectorization with the minimum ↵Wei Mi2015-08-251-22/+25
| | | | | | | | | | | loop iterations check. The loop minimum iterations check below ensures the loop has enough trip count so the generated vector loop will likely be executed, and it covers the overflow check. Differential Revision: http://reviews.llvm.org/D12107. llvm-svn: 245952
* make fast unaligned memory accesses implicit with SSE4.2 or SSE4aSanjay Patel2015-08-251-0/+7
| | | | | | | | | | | | | | | | | | | | | | This is a follow-on from the discussion in http://reviews.llvm.org/D12154. This change allows memset/memcpy to use SSE or AVX memory accesses for any chip that has generally fast unaligned memory ops. A motivating use case for this change is a clang invocation that doesn't explicitly set the CPU, but does target a feature that we know only exists on a CPU that supports fast unaligned memops. For example: $ clang -O1 foo.c -mavx This resolves a difference in lowering noted in PR24449: https://llvm.org/bugs/show_bug.cgi?id=24449 Before this patch, we used different store types depending on whether the example can be lowered as a memset or not. Differential Revision: http://reviews.llvm.org/D12288 llvm-svn: 245950
* Convert SampleProfile pass into a Module pass.Diego Novillo2015-08-255-14/+31
| | | | | | | | | | | Eventually, we will need sample profiles to be incorporated into the inliner's cost models. To do this, we need the sample profile pass to be a module pass. This patch makes no functional changes beyond the mechanical adjustments needed to run SampleProfile as a module pass. llvm-svn: 245940
* [MachO] Introduce MinVersion API.Davide Italiano2015-08-251-0/+18
| | | | | | | | | | | | | While introducing support for MinVersionLoadCommand in llvm-readobj I noticed there's no API to extract Major/Minor/Update components conveniently. Currently consumers do the bit twiddling on their own, but this will change from now on. I'll convert llvm-objdump (and llvm-readobj) in a later commit. Differential Revision: http://reviews.llvm.org/D12282 Reviewed by: rafael llvm-svn: 245938
* [X86] Remove references to _ftol2Michael Kuperstein2015-08-255-54/+0
| | | | | | | As of r245924, _ftol2 is no longer used for fptoui on MS platforms. Remove the dead code associated with it. llvm-svn: 245925
* [X86] Fix fptoui conversionsMichael Kuperstein2015-08-252-69/+143
| | | | | | | | | | | | | | | This fixes two issues in x86 fptoui lowering. 1) Makes conversions from f80 go through the right path on AVX-512. 2) Implements an inline sequence for fptoui i64 instead of a library call. This improves performance by 6X on SSE3+ and 3X otherwise. Incidentally, it also removes the use of ftol2 for fptoui, which was wrong to begin with, as ftol2 converts to a signed i64, producing wrong results for values >= 2^63. Patch by: mitch.l.bodart@intel.com Differential Revision: http://reviews.llvm.org/D11316 llvm-svn: 245924
* Pass function attributes instead of boolean in isIntDivCheap().Steve King2015-08-254-11/+20
| | | | llvm-svn: 245921
* Assume intrinsic handling in global optPiotr Padlewski2015-08-251-0/+4
| | | | | | | | | | | | | | It doesn't solve the problem, when for example we load something, and then assume that it is the same as some constant value, because globalopt will fail on unknown load instruction. The proposed solution would be to skip some instructions that we can't evaluate and they are safe to skip (f.e. load, assume and many others) and see if they are required to perform optimization (f.e. we don't care about ephemeral instructions that may appear using @llvm.assume()) http://reviews.llvm.org/D12266 llvm-svn: 245919
* Revert "Fix LLVM C API for DataLayout"Mehdi Amini2015-08-251-8/+22
| | | | | | | | This reverts commit 433bfd94e4b7e3cc3f8b08f8513ce47817941b0c. Broke some bot, have to see why it passed locally. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 245917
* Fix LLVM C API for DataLayoutMehdi Amini2015-08-251-22/+8
| | | | | | | | | | | | | | | | | | | | | | | | | We removed access to the DataLayout on the TargetMachine and deprecated the C API function LLVMGetTargetMachineData() in r243114. However the way I tried to be backward compatible was broken: I changed the wrapper of the TargetMachine to be a structure that includes the DataLayout as well. However the TargetMachine is also wrapped by the ExecutionEngine, in the more classic way. A client using the TargetMachine wrapped by the ExecutionEngine and trying to get the DataLayout would break. It seems tricky to solve the problem completely in the C API implementation. This patch tries to address this backward compatibility in a more lighter way in the C++ API. The C API is restored in its original state and the removed C++ API is reintroduced, but privately. The C API is friended to the TargetMachine and should be the only consumer for this API. Reviewers: ributzka Differential Revision: http://reviews.llvm.org/D12263 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 245916
OpenPOWER on IntegriCloud