summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Sink DI metadata usage out of MachineInstr.h and MachineInstrBuilder.hReid Kleckner2016-04-149-0/+57
| | | | | | | | | | | MachineInstr.h and MachineInstrBuilder.h are very popular headers, widely included across all LLVM backends. It turns out that there only a handful of TUs that actually care about DI operands on MachineInstrs. After this change, touching DebugInfoMetadata.h and rebuilding llc only needs 112 actions instead of 542. llvm-svn: 266351
* [ValueMapper] Range-loopify to improve readability. NFC.Davide Italiano2016-04-141-3/+3
| | | | llvm-svn: 266350
* [lanai] Add custom lowering for SRL_PARTS i32.Jacques Pienaar2016-04-142-1/+44
| | | | llvm-svn: 266349
* [GlobalISel] Move GISelAccessor class into public headersTom Stellard2016-04-144-48/+15
| | | | | | | | | | Reviewers: qcolombet Subscribers: joker.eph, vkalintiris, llvm-commits Differential Revision: http://reviews.llvm.org/D19120 llvm-svn: 266348
* [DivergenceAnalysis] Treat PHI with incoming undef as constantNicolai Haehnle2016-04-142-1/+19
| | | | | | | | | | | | | | | | | | | | | | | Summary: If a PHI has an incoming undef, we can pretend that it is equal to one non-undef, non-self incoming value. This is particularly relevant in combination with the StructurizeCFG pass, which introduces PHI nodes with undefs. Previously, this lead to branch conditions that were uniform before StructurizeCFG to become non-uniform afterwards, which confused the SIAnnotateControlFlow pass. This fixes a crash when Mesa radeonsi compiles a shader from dEQP-GLES3.functional.shaders.switch.switch_in_for_loop_dynamic_vertex Reviewers: arsenm, tstellarAMD, jingyue Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19013 llvm-svn: 266347
* [StructurizeCFG] Annotate branches that were treated as uniformNicolai Haehnle2016-04-143-4/+30
| | | | | | | | | | | | | | | | | | | Summary: This fully solves the problem where the StructurizeCFG pass does not consider the same branches as uniform as the SIAnnotateControlFlow pass. The patch in D19013 helps with this problem, but is not sufficient (and, interestingly, causes a "regression" with one of the existing test cases). No tests included here, because tests in D19013 already cover this. Reviewers: arsenm, tstellarAMD Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D19018 llvm-svn: 266346
* AMDGPU: Remove SIFixSGPRLiveRanges passNicolai Haehnle2016-04-144-242/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This pass is unnecessary and overly conservative. It was motivated by situations like def %vreg0:SGPR_32 ... if-block: .. def %vreg1:SGPR_32 ... else-block: ... use %vreg0:SGPR_32 ... and similar situations with uses after the non-uniform control flow, where we are not allowed to assign %vreg0 and %vreg1 to the same physical register, even though in the original, thread/workitem-based CFG, it looks like the live ranges of these registers do not overlap. However, by the time register allocation runs, we have moved to a wave-based CFG that accurately represents the fact that the wave may run through both the if- and the else-block. So the live ranges of %vreg0 and %vreg1 already overlap even without the SIFixSGPRLiveRanges pass. In addition to proving this change correct, I have tested it with Piglit and a small number of other tests. Reviewers: arsenm, tstellarAMD Subscribers: MatzeB, arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D19041 llvm-svn: 266345
* AMDGPU: change a redundant if () to an assert(). NFCNicolai Haehnle2016-04-141-2/+1
| | | | | | | | | | | | | | | Summary: I've been carrying this change around with me for a while, because the if () managed to confuse me while following the code. All callers ensure that the assertion holds. Reviewers: arsenm, tstellarAMD Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D19042 llvm-svn: 266344
* [GlobalISel] Coding style and whitespace fixesTom Stellard2016-04-143-8/+8
| | | | | | | | | | Reviewers: qcolombet Subscribers: joker.eph, llvm-commits, vkalintiris Differential Revision: http://reviews.llvm.org/D19119 llvm-svn: 266342
* AArch64: expand cmpxchg after regalloc at -O0.Tim Northover2016-04-144-4/+314
| | | | | | | | | | | | | | | | | | | FastRegAlloc works only at the basic-block level and spills all live-out registers. Unfortunately for a stack-based cmpxchg near the spill slots, this can perpetually clear the exclusive monitor, which means the cmpxchg will never succeed. I believe the only way to handle this within LLVM is by expanding the loop post-regalloc. We don't want this in general because it severely limits the optimisations that can be done, so we limit this to -O0 compilations. It's an ugly hack, and about the one good point in the whole mess is that we can treat all cmpxchg operations in the most naive way possible (seq_cst, no clrex faff) without affecting correctness. Should fix PR25526. llvm-svn: 266339
* [lanai] Add areMemAccessesTriviallyDisjoint, getMemOpBaseRegImmOfs and ↵Jacques Pienaar2016-04-142-2/+103
| | | | | | | | | | | | | | getMemOpBaseRegImmOfsWidth. Summary: Add getMemOpBaseRegImmOfsWidth to enable determining independence during MiSched. Reviewers: eliben, majnemer Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18903 llvm-svn: 266338
* AMDGPU: allow specifying a workgroup size that needs to fit in a compute unitTom Stellard2016-04-146-63/+94
| | | | | | | | | | | | | | | | | | | Summary: For GL_ARB_compute_shader we need to support workgroup sizes of at least 1024. However, if we want to allow large workgroup sizes, we may need to use less registers, as we have to run more waves per SIMD. This patch adds an attribute to specify the maximum work group size the compiled program needs to support. It defaults, to 256, as that has no wave restrictions. Reducing the number of registers available is done similarly to how the registers were reserved for chips with the sgpr init bug. Reviewers: mareko, arsenm, tstellarAMD, nhaehnle Subscribers: FireBurn, kerberizer, llvm-commits, arsenm Differential Revision: http://reviews.llvm.org/D18340 Patch By: Bas Nieuwenhuizen llvm-svn: 266337
* AMDGPU/SI: Use the correct scratch wave offset register for shaders.Tom Stellard2016-04-143-9/+38
| | | | | | | | | | | | | | | | | | | | | | Summary: The code previously always used s1 as it was using the user + system SGPR information for compute kernels. This is incorrect for Mesa shaders though, The register should be the next SGPR after all user and system SGPR's. We use that Mesa adds arguments for all input and system SGPR's and take the next available SGPR for the scratch wave offset register. Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewers: mareko, arsenm, nhaehnle, tstellarAMD Subscribers: qcolombet, arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D18941 Patch By: Bas Nieuwenhuizen llvm-svn: 266336
* [PGO] Do not attach VP metadata if value count at site is 0 [NFC] Betul Buyukkurt2016-04-141-0/+2
| | | | llvm-svn: 266335
* [SCEV][LAA] Add tests for SCEV expression transformations performed during LAASilviu Baranga2016-04-142-0/+28
| | | | | | | | | | | | | | | | | | | | Summary: Add a print method to Predicated Scalar Evolution which prints all interesting transformations done by PSE. Loop Access Analysis will now print this as part of the analysis output. We now use this to check the exact expression transformations that were done by PSE in LAA. The additional checking also acts as white-box testing for the getAsAddRec method. Reviewers: anemet, sanjoy Subscribers: sanjoy, mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D18792 llvm-svn: 266334
* Summary:Simon Dardis2016-04-142-1/+7
| | | | | | | | | | Alias 'jic $reg, 0' to 'jrc $reg' and 'jialc $reg, 0' to 'jalrc $reg' like binutils. This patch was previous committed as r266055 as seemed to have caused some spurious test failures. They did not reappear after further local testing. llvm-svn: 266301
* [Coverage] Avoid unnecessary copying of std::vectorIgor Kudrin2016-04-141-7/+16
| | | | | | | | Approved by: Justin Bogner <mail@justinbogner.com> Differential Revision: http://reviews.llvm.org/D18756 llvm-svn: 266284
* Revert "Support arbitrary addrspace pointers in masked load/store intrinsics"Adam Nemet2016-04-142-49/+10
| | | | | | | | This reverts commit r266086. It breaks the LTO build of gcc in SPEC2000. llvm-svn: 266282
* ThinLTO: linkonce compile-time optimization, do not bother when there is ↵Mehdi Amini2016-04-141-0/+4
| | | | | | | only one input file From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266281
* [CodeGen] Teach LLVM how to lower @llvm.{min,max}num to {MIN,MAX}NANDavid Majnemer2016-04-146-18/+59
| | | | | | | | | | | | | | | The behavior of {MIN,MAX}NAN differs from that of {MIN,MAX}NUM when only one of the inputs is NaN: -NUM will return the non-NaN argument while -NAN would return NaN. It is desirable to lower to @llvm.{min,max}num to -NAN if they don't have a native instruction for -NUM. Notably, ARMv7 NEON's vmin has the -NAN semantics. N.B. Of course, it is only safe to do this if the intrinsic call is marked nnan. llvm-svn: 266279
* Do not use getGlobalContext()... ever.Mehdi Amini2016-04-141-5/+5
| | | | | | | | This code was creating a new type in the global context, regardless of which context the user is sitting in, what can possibly go wrong? From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266275
* AMDGPU: Implement canonicalizeMatt Arsenault2016-04-146-1/+59
| | | | | | Also add generic DAG node for it. llvm-svn: 266272
* TargetLowering: Factor out common code for tail call eligibility checking; NFCMatthias Braun2016-04-144-63/+36
| | | | llvm-svn: 266270
* [CFLAA] Fix up code style a bit. NFC.George Burgess IV2016-04-132-292/+276
| | | | llvm-svn: 266262
* ARM: override cost function to re-enable ConstantHoisting (& fix it).Tim Northover2016-04-133-5/+21
| | | | | | | | | | | | | | | | At some point, ARM stopped getting any benefit from ConstantHoisting because the pass called a different variant of getIntImmCost. Reimplementing the correct variant revealed some problems, however: + ConstantHoisting was modifying switch statements. This is simply invalid, the cases must remain integer constants no matter the notional cost. + ConstantHoisting was mangling alloca instructions in the entry block. These should be handled by FrameLowering, so constants actually have a cost of 0. Worse, the resulting bitcasts meant they became dynamic allocas. rdar://25707382 llvm-svn: 266260
* Revert "Add LLVMGetAttrKindIDInContext in the C API in order to facilitate ↵Amaury Sechet2016-04-131-12/+0
| | | | | | | | migration away from LLVMAttribute" This reverts commit 0bcfd95c268bcb180a525e1837e84475df8acdc7. llvm-svn: 266259
* ValueMapper: Resolve cycles on the new nodesDuncan P. N. Exon Smith2016-04-131-2/+4
| | | | | | | | | | | | | | Fix a major bug from r265456. Although it's now much rarer, ValueMapper sometimes has to duplicate cycles. The might-transitively-reference-a-temporary counts don't decrement on their own when there are cycles, and you need to call MDNode::resolveCycles to fix it. r265456 was checking the input nodes to see if they were unresolved. This is useless; they should never be unresolved. Instead we should check the output nodes and resolve cycles on them. llvm-svn: 266258
* Add LLVMGetAttrKindIDInContext in the C API in order to facilitate migration ↵Amaury Sechet2016-04-131-0/+12
| | | | | | | | | | | | | | away from LLVMAttribute Summary: LLVMAttribute has outlived its utility and is becoming a problem for C API users that what to use all the LLVM attributes. In order to help moving away from LLVMAttribute in a smooth manner, this diff introduce LLVMGetAttrKindIDInContext, which can be used instead of the enum values. Reviewers: Wallbraker, whitequark, joker.eph, echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18749 llvm-svn: 266257
* ARM: Use a callee save register for the swiftself parameter.Matthias Braun2016-04-133-23/+49
| | | | | | | | | | | | | | | | | | It is very likely that the swiftself parameter is alive throughout most functions function so putting it into a callee save register should avoid spills for the callers with only a minimum amount of extra spills in the callees. Currently the generated code is correct but unnecessarily spills and reloads arguments passed in callee save registers, I will address this in upcoming patches. This also adds a missing check that for tail calls the preserved value of the caller must be the same as the callees parameter. Differential Revision: http://reviews.llvm.org/D18901 llvm-svn: 266253
* X86: Use a callee save register for the swiftself parameter.Matthias Braun2016-04-133-8/+40
| | | | | | | | | | | | | | | | | | It is very likely that the swiftself parameter is alive throughout most functions function so putting it into a callee save register should avoid spills for the callers with only a minimum amount of extra spills in the callees. Currently the generated code is correct but unnecessarily spills and reloads arguments passed in callee save registers, I will address this in upcoming patches. This also adds a missing check that for tail calls the preserved value of the caller must be the same as the callees parameter. Differential Revision: http://reviews.llvm.org/D18902 llvm-svn: 266252
* AArch64: Use a callee save registers for swiftself parametersMatthias Braun2016-04-133-15/+44
| | | | | | | | | | | | | | | | | | It is very likely that the swiftself parameter is alive throughout most functions function so putting it into a callee save register should avoid spills for the callers with only a minimum amount of extra spills in the callees. Currently the generated code is correct but unnecessarily spills and reloads arguments passed in callee save registers, I will address this in upcoming patches. This also adds a missing check that for tail calls the preserved value of the caller must be the same as the callees parameter. Differential Revision: http://reviews.llvm.org/D19007 llvm-svn: 266251
* Return immediately from analyzeCall if analyzeBlock returns false.Easwaran Raman2016-04-131-14/+2
| | | | | | This is part of the patch reviewed at http://reviews.llvm.org/D17584 llvm-svn: 266249
* Start to add real error messages for malformed Mach-O files.Kevin Enderby2016-04-131-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And update the existing test cases in test/Object/macho-invalid.test to use llvm-objdump with the -macho option to produce these error messages and stop producing the generic "Invalid data was encountered while parsing the file" message. Working from the beginning of the file, if the mach header is too large for the size of the file and then if the load commands that follow extend past the end of the file these two errors now generate correct error messages. Both of these have existing test cases in test/Object/macho-invalid.test . But the first with macho-invalid-header it will never trigger the error message "mach header extends past the end of the file" using any of the llvm tools as they all use identify_magic() which rejects files with the correct magic number that are too small in size. So I tested this by hacking that code and seeing the error message down in parseHeader() really does happen. So in case there is ever code in llvm that directly calls createMachOObjectFile() this error message will be correctly produced. The second error message of "load commands extends past the end of the file" is triggered by a number of existing tests cases in test/Object/macho-invalid.test . Also other tests trigger different error messages now like "ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table". There are two existing test cases that still get the "Invalid data was encountered ..." error messages that I will tackle next. But they will involve a bit of pluming an Expect<...> up through the call stack and I want to do those as separate changes. FYI, for those test cases that were trying to test specific errors that now get different errors I’ll fix those in follow on changes and create new test cases for those so they test the error they were meant to test. llvm-svn: 266248
* NFC mergefunc: const correctnessJF Bastien2016-04-131-18/+20
| | | | | | Some of the comparators were const others weren't making it annoying to add new comparators which call existing ones. llvm-svn: 266247
* AMDGPU/SI: Add support for spilling VGPRs without having to scavenge registersTom Stellard2016-04-132-11/+29
| | | | | | | | | | | | | | | Summary: When we are spilling SGPRs to scratch memory, we usually don't have free SGPRs to do the address calculation, so we need to re-use the ScratchOffset register for the calculation. Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D18917 llvm-svn: 266244
* AsmParser: record "# line file" context to calculate location for diagTim Northover2016-04-131-30/+40
| | | | | | | | | | | Since we can't emit diagnostics for missing "jmp 1f" labels until the end of the file, we need to be able to restore the context used to calculate file/line. This is basically the "# line file" directive that's being used at the time the expression is seen. rdar://25706972 llvm-svn: 266238
* LibDriver: Silently do nothing when provided no inputs.Peter Collingbourne2016-04-131-2/+2
| | | | | | | | | This behavior is strange, but it matches lib.exe. Based on a patch by Nico Weber. Fixes PR27335. llvm-svn: 266236
* [PGO] Remove redundant VP instrumentationBetul Buyukkurt2016-04-131-0/+16
| | | | | | | | LLVM optimization passes may reduce a profiled target expression to a constant. Removing runtime calls at such instrumentation points would help speedup the runtime of the instrumented program. llvm-svn: 266229
* [PowerPC] Basic support for P9 byte comparison and count trailing zero insnsNemanja Ivanovic2016-04-135-8/+75
| | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D17850 This patch implements the following instructions: cmprb, cmpeqb, cnttzw, cnttzw., cnttzd, cnttzd. llvm-svn: 266228
* [AArch64] Disable LDP/STP for quadsEvandro Menezes2016-04-131-0/+14
| | | | | | | | | Disable LDP/STP for quads on Exynos M1 as they are not as efficient as pairs of regular LDR/STR. Patch by Abderrazek Zaafrani <a.zaafrani@samsung.com>. llvm-svn: 266223
* Revert "[IR/Verifier] Each DISubprogram with isDefinition: true must belong ↵Davide Italiano2016-04-131-16/+0
| | | | | | | | | to a CU." This reverts commit r266102. The O(N^2) verifier check causes timeouts in LTO test suite. llvm-svn: 266221
* [IR/DebugInfoMetadata] Simplify array length calculation by using ↵David Blaikie2016-04-131-4/+3
| | | | | | array_lengthof instead of ArrayRef::size llvm-svn: 266218
* Cleanup Store Merging in UseAA caseNirav Dave2016-04-131-30/+44
| | | | | | | | | | | | | | This patch fixes a bug (PR26827) when using anti-aliasing in store merging. This sets the chain users of the component stores to point to the new store instead of the component stores chain parent. Reviewers: jyknight Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18909 llvm-svn: 266217
* Revert "Make aliases explicit in the summary"Mehdi Amini2016-04-134-173/+36
| | | | | | | | | Inadvertently commited... This reverts commit e618ec93786d99df2ddf280ad2d5e02f5516cecf. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266215
* Make aliases explicit in the summaryMehdi Amini2016-04-134-36/+173
| | | | | | | | | | | | | | | | Summary: To be able to work accurately on the reference graph when taking decision about internalizing, promoting, renaming, etc. We need to have the alias information explicit. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18836 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266214
* AArch64: don't create instructions that write to xzr/wzr twice.Tim Northover2016-04-131-0/+8
| | | | | | | | These are unpredictable even on AArch64. Patch by Yichao Yu. llvm-svn: 266206
* [AMDGPU][llvm-mc] Support of Trap Handler registers (TTMP0..11 and ↵Artem Tamazov2016-04-135-37/+165
| | | | | | | | | | | | | | | TBA/TMA)git status Tests added along with implemented feature. Note that there is a small leftover of unecessary MI sheduling issue (more info in the review). CodeGen/AMDGPU/salu-to-valu.ll updated to fix the false regression. TODO: Support for TTMP quads, comma-separated syntax in "[]" and more. Differential Revision: http://reviews.llvm.org/D17825 llvm-svn: 266205
* [mips] Fix emitAtomicCmpSwapPartword to handle 64 bit pointers correctlyZoran Jovanovic2016-04-131-6/+11
| | | | | | Differential Revision: http://reviews.llvm.org/D18995 llvm-svn: 266204
* [mips] Sign-extend i32 values truncated from previously zero-extended i32 ↵Vasileios Kalintiris2016-04-132-1/+49
| | | | | | | | | | | | | | | | | | | | values. Summary: This is a special case for MIPS64 because the architecture requires properly 32-bit sign-extended values in the register containers. Additionaly, we merge consecutive trunc + AssertZExt nodes in order to avoid unnecessary sign-extensions when the extension comes from a type smaller than i32. Reviewers: dsanders Subscribers: dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D18893 llvm-svn: 266203
* Simplify strlen to a subtraction for certain cases.David L Kreitzer2016-04-132-13/+72
| | | | | | | | Patch by Li Huang (li1.huang@intel.com) Differential Revision: http://reviews.llvm.org/D18230 llvm-svn: 266200
OpenPOWER on IntegriCloud