summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [MIR Serialization] static -> static const in ↵Hal Finkel2015-08-303-5/+5
| | | | | | | | | getSerializable*MachineOperandTargetFlags Make the arrays 'static const' instead of just 'static'. Post-commit review comment from Roman Divacky on IRC. NFC. llvm-svn: 246376
* Update for several APIs in LLVM that now use StringRefs rather thanChandler Carruth2015-08-304-23/+17
| | | | | | | | const char pointers. In turn, push this through Clang APIs as well, simplifying a number of bits of code that was handling the oddities of nullptrs. llvm-svn: 246375
* Teach the target parsing framework to directly compute the length of allChandler Carruth2015-08-305-96/+123
| | | | | | | | | | of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
* [PowerPC/MIR Serialization] Target flags serialization supportHal Finkel2015-08-303-0/+121
| | | | | | | | | | | | | Add support for MIR serialization of PowerPC-specific operand target flags (based on the generic infrastructure added in r244185 and r245383). I won't even pretend that this is good test coverage, but this includes the regression test associated with r246372. Adding an MIR test for that fix is far superior to adding an IR-level test because particular instruction-scheduling decisions are necessary in order to expose the bug, and using an MIR test we can start the pipeline post-scheduling. llvm-svn: 246373
* [PowerPC] Don't assume ADDISdtprelHA's source is r3Hal Finkel2015-08-301-5/+5
| | | | | | | | | | | | Even through ADDISdtprelHA generally has r3 as its source register, it is possible for the instruction scheduler to move things around such that some other register is the source. We need to print the actual source register, not always r3. Fixes PR24394. The test case will come in a follow-up commit because it depends on MIR target-flags parsing. llvm-svn: 246372
* New interface function is added to VectorUtilsElena Demikhovsky2015-08-303-17/+44
| | | | | | | | | | | | | Value *getSplatValue(Value *Val); It complements the CreateVectorSplat(), which creates 2 instructions - insertelement and shuffle with all-zero mask. The new function recognizes the pattern - insertelement+shuffle and returns the splat value (or nullptr). It also returns a splat value form ConstantDataVector, for completeness. Differential Revision: http://reviews.llvm.org/D11124 llvm-svn: 246371
* Refactor the ARM target parsing to use a def file with macros to expandChandler Carruth2015-08-303-222/+222
| | | | | | | | | | | | | | the necessary tables. This will allow me to restructure the code and structures using this to be significantly more efficient. It also removes the duplication of the list of several enumerators. It also enshrines that the order of enumerators match the order of the entries in the tables, something the implementation code actually uses. No functionality changed (yet). llvm-svn: 246370
* [Triple] Use clang-format to normalize the formatting of the ARM targetChandler Carruth2015-08-302-204/+189
| | | | | | | | | | | | | parsing logic prior to making substantial changes to it. This parsing logic is incredibly wasteful, so I'm planning to rewrite it. Just unittesting the triple parsing logic spends well over 80% of its time in the ARM parsing logic, and others have measured significant time spent here in real production compiles. Stay tuned... llvm-svn: 246369
* Update for API change in LLVM: ARMTargetParser class is just the ARMChandler Carruth2015-08-303-22/+22
| | | | | | namespace. llvm-svn: 246368
* [Triple] Stop abusing a class to have only static methods and just useChandler Carruth2015-08-306-85/+75
| | | | | | | the namespace that we are already using for the enums that are produced by the parsing. llvm-svn: 246367
* SelectionDAG: add missing ComputeSignBits case for SELECT_CCFiona Glaser2015-08-291-0/+5
| | | | | | Identical to SELECT, just with different operand numbers. llvm-svn: 246366
* Fix shared library build.Peter Collingbourne2015-08-291-0/+7
| | | | llvm-svn: 246365
* Remove some code duplication when creating Allocas [NFC]Tobias Grosser2015-08-292-22/+22
| | | | llvm-svn: 246364
* [X86] Reapplied r246204, r246206, r246211, r246223Simon Pilgrim2015-08-294-4/+136
| | | | | | | | (Re)added debug codegen test for F16C, FMA4, XOP + 3DNow! intrinsics Part of PR24590 llvm-svn: 246363
* [ELFv2] Implement R_X86_64_32 relocation.Davide Italiano2015-08-292-2/+18
| | | | | | Differential Revision: http://reviews.llvm.org/D12436 llvm-svn: 246362
* [ARM] Fix up buildbots after r246360James Molloy2015-08-291-2/+2
| | | | | | I have no idea how I missed this in my internal testing. Just no idea. Sorry for the bot-armageddon. llvm-svn: 246361
* [ARM] Hoist fabs/fneg above a conversion to float.James Molloy2015-08-292-1/+57
| | | | | | | | | | | | | | | | | | This is especially visible in softfp mode, for example in the implementation of libm fabs/fneg functions. If we have: %1 = vmovdrr r0, r1 %2 = fabs %1 then move the fabs before the vmovdrr: %1 = and r1, #0x7FFFFFFF %2 = vmovdrr r0, r1 This is never a lose, and could be a serious win because the vmovdrr may be followed by a vmovrrd, which would enable us to remove the conversion into FPRs completely. We already do this for f32, but not for f64. Tests are added for both. llvm-svn: 246360
* [AST] Don't crash when comparing incomplete objectDavid Majnemer2015-08-292-1/+11
| | | | | | | | | | We cannot tell if an object is past-the-end if its type is incomplete. Zero sized objects satisfy past-the-end criteria and our object might turn out to be such an object. This fixes PR24622. llvm-svn: 246359
* AMDGPU: Add sdst operand to VOP2b instructionsMatt Arsenault2015-08-2918-108/+165
| | | | | | | | | | The VOP3 encoding of these allows any SGPR pair for the i1 output, but this was forced before to always use vcc. This doesn't yet try to use this, but does add the operand to the definitions so the main change is adding vcc to the output of the VOP2 encoding. llvm-svn: 246358
* AMDGPU: Set mem operands for spill instructionsMatt Arsenault2015-08-293-25/+55
| | | | llvm-svn: 246357
* AMDGPU: Fix dropping mem operands when moving to VALUMatt Arsenault2015-08-292-11/+64
| | | | | | | | | | | | | Without a memory operand, mayLoad or mayStore instructions are treated as hasUnorderedMemRef, which results in much worse scheduling. We really should have a verifier check that any non-side effecting mayLoad or mayStore has a memory operand. There are a few instructions (interp and images) which I'm not sure what / where to add these. llvm-svn: 246356
* Add a check for a function we're not testing.Eric Christopher2015-08-291-0/+1
| | | | llvm-svn: 246355
* AMDGPU/SI: Fix some invaild assumptions when folding 64-bit immediatesTom Stellard2015-08-291-1/+5
| | | | | | | | | | | | | | | Summary: We were assuming tha if the use operand had a sub-register that the immediate was 64-bits, but this was breaking the case of folding a 64-bit immediate into another 64-bit instruction. Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D12255 llvm-svn: 246354
* AMDGPU/SI: Factor operand folding code into its own functionTom Stellard2015-08-281-67/+79
| | | | | | | | | | Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D12254 llvm-svn: 246353
* Revert r246350, "The host and default target triples do not need to match ↵NAKAMURA Takumi2015-08-281-2/+5
| | | | | | | | for "native"" Wrong assumption. Consider --host=x86_64-linux --target=(i686|x86_64)-win32. See also r193459. llvm-svn: 246352
* DI: Update tests before adding !dbg subprogram attachmentsDuncan P. N. Exon Smith2015-08-283-4/+14
| | | | | | | | | | | | | | | | | | | | I'm working on adding !dbg attachments to functions (PR23367), which we'll use to determine the canonical subprogram for a function (instead of the `subprograms:` array in the compile units). This updates a few old tests in preparation. Transforms/Mem2Reg/ConvertDebugInfo2.ll had an old-style grep+count based test that would start to fail because I've added an extra line with `!dbg`. Instead, explicitly `CHECK` for what I think the test actually cares about. All three testcases have subprograms with a valid `function:` reference -- which means my upgrade script will add a `!dbg` attachment -- but that aren't referenced from any compile unit. I suspect these testcases were handreduced over-zealously (or have bitrotted?). Add a reference from the compile unit so that upcoming Verifier checks won't fail here. llvm-svn: 246351
* The host and default target triples do not need to match for "native"Paul Robinson2015-08-281-5/+2
| | | | | | | | backend to work. Differential Revision: http://reviews.llvm.org/D12454 llvm-svn: 246350
* DI: Set DILexicalBlock columns >= 65536 to 0/unknownDuncan P. N. Exon Smith2015-08-283-2/+33
| | | | | | | | | This fixes PR24621 and matches what we do for `DILocation`. Although the limit seems somewhat artificial, there are places in the backend that also assume 16-bit columns, so we may as well just be consistent about the limits. llvm-svn: 246349
* Follow-up to r246338: use getParentFunctionOrMethodHans Wennborg2015-08-281-1/+1
| | | | llvm-svn: 246348
* PR24612: Don't bail out of checking a constexpr function before checkingRichard Smith2015-08-282-6/+14
| | | | | | | whether it can ever produce a constant expression in the case where it has a void return type and no return statements. llvm-svn: 246347
* Fold TargetInfo::handleUserFeatures into TargetInfo::initFeatureMap.Eric Christopher2015-08-282-62/+46
| | | | llvm-svn: 246346
* [analyzer] When memcpy'ing into a fixed-size array, do not invalidate entire ↵Devin Coughlin2015-08-284-10/+866
| | | | | | | | | | | | | | | | | | region. Change the analyzer's modeling of memcpy to be more precise when copying into fixed-size array fields. With this change, instead of invalidating the entire containing region the analyzer now invalidates only offsets for the array itself when it can show that the memcpy stays within the bounds of the array. This addresses false positive memory leak warnings of the kind reported by krzysztof in https://llvm.org/bugs/show_bug.cgi?id=22954 A patch by Pierre Gousseau! Differential Revision: http://reviews.llvm.org/D11832 llvm-svn: 246345
* Use UNSUPPORTED instead of XFAIL to disable this test, as it passes on one ↵Peter Collingbourne2015-08-281-1/+1
| | | | | | AArch64 bot. llvm-svn: 246344
* lit: Match UNSUPPORTED against target triple as we do for XFAIL.Peter Collingbourne2015-08-281-0/+7
| | | | llvm-svn: 246343
* COFF: Implement parallel LTO code generation.Peter Collingbourne2015-08-287-37/+89
| | | | | | | | | This is exposed via a new flag /opt:lldltojobs=N, where N is the number of code generation threads. Differential Revision: http://reviews.llvm.org/D12309 llvm-svn: 246342
* DI: Fix testcases after LLVM r246327Duncan P. N. Exon Smith2015-08-2811-13/+13
| | | | | | | | | | I ran the script from r246327 and it touched all the right files; committing now to hopefully right the bots, but if my check-polly doesn't come back clean I'll keep looking. http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/33648 llvm-svn: 246341
* [X86] NFC: Clean up and clang-format a few linesVedant Kumar2015-08-281-5/+5
| | | | llvm-svn: 246340
* DI: Add Function::getSubprogram()Duncan P. N. Exon Smith2015-08-285-1/+68
| | | | | | | | | | | | | | | | | | Add `Function::setSubprogram()` and `Function::getSubprogram()`, convenience methods to forward to `setMetadata()` and `getMetadata()`, respectively, and deal in `DISubprogram` instead of `MDNode`. Also add a verifier check to enforce that `!dbg` attachments are always subprograms. Originally (when I had the llvm-dev discussion back in April) I thought I'd store a pointer directly on `llvm::Function` for these attachments -- we frequently have debug info, and that's much cheaper than using map in the context if there are no other function-level attachments -- but for now I'm just using the generic infrastructure. Let's add the extra complexity only if this shows up in a profile. llvm-svn: 246339
* Allow TLS vars in dllimport/export functions; only inline dllimport ↵Hans Wennborg2015-08-285-4/+111
| | | | | | | | | | | | | | | | | | | | | functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
* [Mips] Support grouping of multiple consecutive relocations in case of N32 ↵Simon Atanasyan2015-08-282-1/+83
| | | | | | and 64-bit MIPS ABIs llvm-svn: 246337
* [Mips] Support two more MIPS linking emulation options ↵Simon Atanasyan2015-08-282-2/+8
| | | | | | elf32btsmipn32/elf32ltsmipn32 llvm-svn: 246336
* [Mips] Make "emulation" option less dependent on the "-target" option.Simon Atanasyan2015-08-282-11/+17
| | | | | | | Now it is possible to have mips-linux-gnu-ld executable and link MIPS 64-bit little-endian binaries providing -melf64ltsmip command line argument. llvm-svn: 246335
* [Mips] Initial support of the MIPS N32 ABISimon Atanasyan2015-08-2810-10/+253
| | | | llvm-svn: 246334
* AsmPrinter: Allow null subroutine typeDuncan P. N. Exon Smith2015-08-284-9/+5
| | | | | | | | | | | | | | | | | | | | | | Currently the DWARF backend requires that subprograms have a type, and the type is ignored if it has an empty type array. The long term direction here -- see PR23079 -- is instead to skip the type entirely if there's no valid type. It turns out we have cases in tree of missing types on subprograms, but since they're not referenced by compile units, the backend never crashes on them. One option would be to add a Verifier check that subprograms have types, and fix the bitrot. However, this is a fair bit of churn (20-30 testcases) that would be reversed anyway by PR23079. I found this inconsistency because of a WIP patch and upgrade script for PR23367 that started crashing on test/DebugInfo/2010-10-01-crash.ll. This commit updates the testcase to reference the subprogram from the compile unit, and fixes the resulting crash (in line with the direction of PR23079). This also updates `DIBuilder` to stop assuming a non-null pointer for the subroutine types. llvm-svn: 246333
* Start adding support for common symbols.Rafael Espindola2015-08-284-8/+38
| | | | | | For now this just recognizes the special section number. llvm-svn: 246332
* Revert r246232 and r246304.David Majnemer2015-08-283-32/+51
| | | | | | | | | This reverts isSafeToSpeculativelyExecute's use of ReadNone until we split ReadNone into two pieces: one attribute which reasons about how the function reasons about memory and another attribute which determines how it may be speculated, CSE'd, trap, etc. llvm-svn: 246331
* [compiler-rt] [tsan] Enable TSan for AArch64/42-bit VMAAdhemerval Zanella2015-08-2810-9/+64
| | | | | | | | | | | This patch adds support for tsan on aarch64-linux with 42-bit VMA (current default config for 64K pagesize kernels). The support is enabled by defining the SANITIZER_AARCH64_VMA to 42 at build time for both clang/llvm and compiler-rt. The default VMA is 39 bits. It also enabled tsan for previous supported VMA (39). llvm-svn: 246330
* Remove white space (test commit)Matthew Simpson2015-08-281-3/+3
| | | | llvm-svn: 246329
* Split the gold tests into X86 and PowerPC directories.Rafael Espindola2015-08-2832-1/+3
| | | | | | Patch by Than McIntosh! llvm-svn: 246328
* DI: Require subprogram definitions to be distinctDuncan P. N. Exon Smith2015-08-28403-928/+753
| | | | | | | | | | | | | | | | | | | | | | | | As a follow-up to r246098, require `DISubprogram` definitions (`isDefinition: true`) to be 'distinct'. Specifically, add an assembler check, a verifier check, and bitcode upgrading logic to combat testcase bitrot after the `DIBuilder` change. While working on the testcases, I realized that test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its purpose was to check for a corner case in PR22792 where two subprogram definitions match exactly and share the same metadata node. The new verifier check, requiring that subprogram definitions are 'distinct', precludes that possibility. I updated almost all the IR with the following script: git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' | grep -v test/Bitcode | xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/' Likely some variant of would work for out-of-tree testcases. llvm-svn: 246327
OpenPOWER on IntegriCloud