summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Revert r339977: [GISel]: Add Opcodes for a few LLVM IntrinsicsChandler Carruth2018-08-171-10/+0
| | | | | | This is breaking ~all the bots. llvm-svn: 339982
* [Support] Add a public API to allow clearing all (static) timer groups.Graydon Hoare2018-08-171-2/+13
| | | | | | | | | | | | | | | | | | | | | | Summary: Formerly, all timer groups were automatically cleared when printed out. In https://reviews.llvm.org/rL324788 this behaviour was changed to not-clearing timers on printout, to allow printing timers more than once, but as a result clients (specifically Swift) that relied on the clear-on-print behaviour to inhibit duplicate timer printing on shutdown were broken. Rather than revert that change, this change adds a new API that enables clients that _want_ to clear all timers to do so explicitly. Reviewers: george.karpenkov, thegameg Reviewed By: george.karpenkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50874 llvm-svn: 339980
* [GISel]: Add Opcodes for a few LLVM IntrinsicsAditya Nandakumar2018-08-171-0/+10
| | | | | | | | | | | https://reviews.llvm.org/D50401 Add opcodes for llvm.intrinsic.trunc, round, and update the IRTranslator for the same. Reviewed by: dsanders. llvm-svn: 339977
* [WebAssembly] Modify LateEHPrepare one-line description (NFC)Heejin Ahn2018-08-171-1/+1
| | | | llvm-svn: 339972
* DebugInfo: Remove command line (& target-based) disabling of pubnames in ↵David Blaikie2018-08-163-14/+2
| | | | | | | | | favor of metadata Now that Clang disables NVPTX pubnames via metadata there's no need for this fallback to target detection in the backend. llvm-svn: 339970
* [WebAssembly] CFG stackify support for exception handlingHeejin Ahn2018-08-161-108/+542
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds support for exception handling to CFGStackify pass. This only adds TRY / END_TRY markers and DOES NOT yet fix unwind mismatches that can be created by the linearization of the CFG into the structural wasm format. The mismatch fix will be added by following patches. In detail, this patch - Added support for TRY / END_TRY markers to support EH - Changed many static functions into class member functions as they take too many arguments now - Added several more bookeeping data structures - Refactored routines that decide where to insert markers, because without refactoring this got too complicated as we added support for new kinds of markers (TRY/END_TRY). - Rewrote rethrow instructions' BB arguments to relative depths in EH pad stack. Reviewers: dschuff, sunfish Subscribers: sbc100, jgravelle-google, llvm-commits Differential Revision: https://reviews.llvm.org/D48273 llvm-svn: 339967
* [x86/MIR] Implement support for pre- and post-instruction symbols, asChandler Carruth2018-08-166-29/+210
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | well as MIR parsing support for `MCSymbol` `MachineOperand`s. The only real way to test pre- and post-instruction symbol support is to use them in operands, so I ended up implementing that within the patch as well. I can split out the operand support if folks really want but it doesn't really seem worth it. The functional implementation of pre- and post-instruction symbols is now *completely trivial*. Two tiny bits of code in the (misnamed) AsmPrinter. It should be completely target independent as well. We emit these exactly the same way as we emit basic block labels. Most of the code here is to give full dumping, MIR printing, and MIR parsing support so that we can write useful tests. The MIR parsing of MC symbol operands still isn't 100%, as it forces the symbols to be non-temporary and non-local symbols with names. However, those names often can encode most (if not all) of the special semantics desired, and unnamed symbols seem especially annoying to serialize and de-serialize. While this isn't perfect or full support, it seems plenty to write tests that exercise usage of these kinds of operands. The MIR support for pre-and post-instruction symbols was quite straightforward. I chose to print them out in an as-if-operand syntax similar to debug locations as this seemed the cleanest way and let me use nice introducer tokens rather than inventing more magic punctuation like we use for memoperands. However, supporting MIR-based parsing of these symbols caused me to change the design of the symbol support to allow setting arbitrary symbols. Without this, I don't see any reasonable way to test things with MIR. Differential Revision: https://reviews.llvm.org/D50833 llvm-svn: 339962
* [InstCombine] add reflection fold for tan(-x)Sanjay Patel2018-08-161-2/+5
| | | | | | | | | This is a follow-up suggested with rL339604. For tan(), we don't have a corresponding LLVM intrinsic -- unlike sin/cos -- so this is the only way/place that we can do this fold currently. llvm-svn: 339958
* [InstrProf] Use atomic profile counter updates for TSanVedant Kumar2018-08-161-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | Thread sanitizer instrumentation fails to skip all loads and stores to profile counters. This can happen if profile counter updates are merged: %.sink = phi i64* ... %pgocount5 = load i64, i64* %.sink %27 = add i64 %pgocount5, 1 %28 = bitcast i64* %.sink to i8* call void @__tsan_write8(i8* %28) store i64 %27, i64* %.sink To suppress TSan diagnostics about racy counter updates, make the counter updates atomic when TSan is enabled. If there's general interest in this mode it can be surfaced as a clang/swift driver option. Testing: check-{llvm,clang,profile} rdar://40477803 Differential Revision: https://reviews.llvm.org/D50867 llvm-svn: 339955
* Update MemorySSA in Local utils removing blocks.Alina Sbirlea2018-08-161-15/+24
| | | | | | | | | | Summary: Extend Local utils to update MemorySSA. Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits Differential Revision: https://reviews.llvm.org/D48790 llvm-svn: 339951
* [DomTree] Add constructor to create a new DT based on current DT/CFG and a ↵Alina Sbirlea2018-08-161-0/+5
| | | | | | | | | | | | | | | | | | | | set of Updates. Summary: Add the posibility of creating a new DT using a set of Updates. This will essentially create a DT based on a CFG snapshot/view. Additional refactoring for either this patch or follow-ups: - create an utility for building BUI. - replace BUI with a GraphDiff. Reviewers: kuhar Subscribers: sanjoy, jlebar, llvm-commits Differential Revision: https://reviews.llvm.org/D50671 llvm-svn: 339947
* [DAGCombiner] Don't reassociate operations that have the vector reduction ↵Craig Topper2018-08-161-9/+13
| | | | | | | | | | | | | | flag set. When nodes are reassociated the vector-reduction flag gets lost. The test case is here is what would happen if you had a sum of absolute differences loop that started with a non-zero but contant sum and that loop was unrolled. The vectorizer will generate a constant vector for the initial value. And DAGCombiner reassociate tries to move it down the addition tree erasing the vector-reduction flag. Interestingly this moves constants the opposite direction of the reassociate IR pass. I've chosen to just punt on the reassociate, but I suppose we could maybe preserve the flag if both nodes have it set. Differential Revision: https://reviews.llvm.org/D50827 llvm-svn: 339946
* [X86] In EFLAGS copy pass, don't emit EXTRACT_SUBREG instructions since ↵Craig Topper2018-08-161-6/+11
| | | | | | | | | | | | | | we're after peephole Normally the peephole pass converts EXTRACT_SUBREG to COPY instructions. But we're after peephole so we can't rely on it to clean these up. To fix this, the eflags pass now emits a COPY with a subreg input. I also noticed that in 32-bit mode we need to constrain the input to the copy to ensure the subreg is valid. Otherwise we'll fail verify-machineinstrs Differential Revision: https://reviews.llvm.org/D50656 llvm-svn: 339945
* Factor Node creation out of the demangler. No functionality changeRichard Smith2018-08-161-77/+99
| | | | | | intended. llvm-svn: 339944
* [MC] Improve COFF associative section lookupReid Kleckner2018-08-161-11/+17
| | | | | | | | | | | | | | | Handle the case when the symbol is private. Private symbols are not in the COFF object file symbol table, so they aren't inserted into SymbolMap. We can't look up the section of the symbol that way. Instead, get the MCSection from the MCSymbol and map that to the object file section. Print a better error message when the symbol has no section, like when the symbol is undefined. Fixes PR38607 llvm-svn: 339942
* [MI] Change the array of `MachineMemOperand` pointers to beChandler Carruth2018-08-1639-403/+399
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a generically extensible collection of extra info attached to a `MachineInstr`. The primary change here is cleaning up the APIs used for setting and manipulating the `MachineMemOperand` pointer arrays so chat we can change how they are allocated. Then we introduce an extra info object that using the trailing object pattern to attach some number of MMOs but also other extra info. The design of this is specifically so that this extra info has a fixed necessary cost (the header tracking what extra info is included) and everything else can be tail allocated. This pattern works especially well with a `BumpPtrAllocator` which we use here. I've also added the basic scaffolding for putting interesting pointers into this, namely pre- and post-instruction symbols. These aren't used anywhere yet, they're just there to ensure I've actually gotten the data structure types correct. I'll flesh out support for these in a subsequent patch (MIR dumping, parsing, the works). Finally, I've included an optimization where we store any single pointer inline in the `MachineInstr` to avoid the allocation overhead. This is expected to be the overwhelmingly most common case and so should avoid any memory usage growth due to slightly less clever / dense allocation when dealing with >1 MMO. This did require several ergonomic improvements to the `PointerSumType` to reasonably support the various usage models. This also has a side effect of freeing up 8 bits within the `MachineInstr` which could be repurposed for something else. The suggested direction here came largely from Hal Finkel. I hope it was worth it. ;] It does hopefully clear a path for subsequent extensions w/o nearly as much leg work. Lots of thanks to Reid and Justin for careful reviews and ideas about how to do all of this. Differential Revision: https://reviews.llvm.org/D50701 llvm-svn: 339940
* DebugInfo: Add metadata support for disabling DWARF pub sectionsDavid Blaikie2018-08-1614-48/+141
| | | | | | | | | | | | | | | | | | | | | | | In cases where the debugger load time is a worthwhile tradeoff (or less costly - such as loading from a DWP instead of a variety of DWOs (possibly over a high-latency/distributed filesystem)) against object file size, it can be reasonable to disable pubnames and corresponding gdb-index creation in the linker. A backend-flag version of this was implemented for NVPTX in D44385/r327994 - which was fine for NVPTX which wouldn't mix-and-match CUs. Now that it's going to be a user-facing option (likely powered by "-gno-pubnames", the same as GCC) it should be encoded in the DICompileUnit so it can vary per-CU. After this, likely the NVPTX support should be migrated to the metadata & the previous flag implementation should be removed. Reviewers: aprantl Differential Revision: https://reviews.llvm.org/D50213 llvm-svn: 339939
* add a missed case for binary op FMF propagation under select foldsMichael Berg2018-08-161-1/+3
| | | | llvm-svn: 339938
* [MemLoc] Fix a bug causing any use of invariant.end to crash in LICMPhilip Reames2018-08-161-0/+4
| | | | | | The fix is fairly simple, but is says something unpleasant about the usage and testing of invariant.start/end scopes that this went undetected. To put this in perspective, *any* invariant.end in a loop flowing through LICM crashed. I haven't bothered to figure out just how far back this goes, but it's not caused by any of the recent changes. We're probably talking months if not years. llvm-svn: 339936
* [LICM][NFC] Restructure pointer invalidation API in terms of MemoryLocationPhilip Reames2018-08-162-25/+17
| | | | | | | | Main value is just simplifying code. I'll further simply the argument handling case in a bit, but that involved a slightly orthogonal change so I went with the mildy ugly intermediate for this patch. Note that the isSized check in the old LICM code was not carried across. It turns out that check was dead. a) no test exercised it, and b) langref and verifier had been updated to disallow unsized types used in loads. llvm-svn: 339930
* [WebAssembly] Remove temporary workaround for function bitcastsJacob Gravelle2018-08-161-5/+0
| | | | | | | | | | | | | | Summary: EM_ASM no longer is lowered as varargs in C, so this workaround is obsolete. Reviewers: dschuff, sunfish Subscribers: sbc100, aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D50859 llvm-svn: 339925
* [MachineVerifier] Check if predecessor is jointly dominated by undefsKrzysztof Parzyszek2018-08-161-1/+11
| | | | | | | | Each use of a value should be jointly dominated by the union of defs and undefs. It can happen that it will only be jointly dominated by undefs, and that is still legal. Make sure that the verifier is aware of that. llvm-svn: 339924
* [SelectionDAG] Improve the legalisation lowering of UMULO.Eli Friedman2018-08-161-17/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no way in the universe, that doing a full-width division in software will be faster than doing overflowing multiplication in software in the first place, especially given that this same full-width multiplication needs to be done anyway. This patch replaces the previous implementation with a direct lowering into an overflowing multiplication algorithm based on half-width operations. Correctness of the algorithm was verified by exhaustively checking the output of this algorithm for overflowing multiplication of 16 bit integers against an obviously correct widening multiplication. Baring any oversights introduced by porting the algorithm to DAG, confidence in correctness of this algorithm is extremely high. Following table shows the change in both t = runtime and s = space. The change is expressed as a multiplier of original, so anything under 1 is “better” and anything above 1 is worse. +-------+-----------+-----------+-------------+-------------+ | Arch | u64*u64 t | u64*u64 s | u128*u128 t | u128*u128 s | +-------+-----------+-----------+-------------+-------------+ | X64 | - | - | ~0.5 | ~0.64 | | i686 | ~0.5 | ~0.6666 | ~0.05 | ~0.9 | | armv7 | - | ~0.75 | - | ~1.4 | +-------+-----------+-----------+-------------+-------------+ Performance numbers have been collected by running overflowing multiplication in a loop under `perf` on two x86_64 (one Intel Haswell, other AMD Ryzen) based machines. Size numbers have been collected by looking at the size of function containing an overflowing multiply in a loop. All in all, it can be seen that both performance and size has improved except in the case of armv7 where code size has regressed for 128-bit multiply. u128*u128 overflowing multiply on 32-bit platforms seem to benefit from this change a lot, taking only 5% of the time compared to original algorithm to calculate the same thing. The final benefit of this change is that LLVM is now capable of lowering the overflowing unsigned multiply for integers of any bit-width as long as the target is capable of lowering regular multiplication for the same bit-width. Previously, 128-bit overflowing multiply was the widest possible. Patch by Simonas Kazlauskas! Differential Revision: https://reviews.llvm.org/D50310 llvm-svn: 339922
* [RegisterCoalescer] Shrink to uses if needed after removeCopyByCommutingDefKrzysztof Parzyszek2018-08-161-24/+54
| | | | llvm-svn: 339912
* Fix memory leak in demangling of string literals.Zachary Turner2018-08-161-0/+1
| | | | llvm-svn: 339909
* [TargetLowering] Add support for non-uniform vectors to BuildSDIVSimon Pilgrim2018-08-161-10/+24
| | | | | | | | | | This patch refactors the existing TargetLowering::BuildSDIV base implementation to support non-uniform constant vector denominators. This is the last patch necessary to close PR36545 Differential Revision: https://reviews.llvm.org/D50765 llvm-svn: 339908
* [codeview] Use push_macro to avoid conflicts instead of a prefixReid Kleckner2018-08-162-172/+172
| | | | | | | | | | | | | | | | | | | | | | | Summary: This prefix was added in r333421, and it changed our dumper output to say things like "CVRegEAX" instead of just "EAX". That's a functional change that I'd rather avoid. I tested GCC, Clang, and MSVC, and all of them support #pragma push_macro. They don't issue warnings whem the macro is not defined either. I don't have a Mac so I can't test the real termios.h header, but I looked at the termios.h sources online and looked for other conflicts. I saw only the CR* macros, so those are the ones we work around. Reviewers: zturner, JDevlieghere Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50851 llvm-svn: 339907
* [MC] Cleanup noop default case spelling. NFC.Nirav Dave2018-08-161-1/+1
| | | | llvm-svn: 339906
* AMDGPU: Custom lower fexpMatt Arsenault2018-08-163-1/+36
| | | | | | | | This will allow the library to just use __builtin_expf directly without expanding this itself. Note f64 still won't work because there is no exp instruction for it. llvm-svn: 339902
* [TargetLowering] Refactor BuildSDIV in preparation for D50765. NFCI.Simon Pilgrim2018-08-161-24/+36
| | | | | | Pull out magic factor calculators into a helper function, use 0/+1/-1 multiplication factor to (optionally) add/sub the numerator. llvm-svn: 339898
* [MC] Remove unused variableBenjamin Kramer2018-08-161-1/+0
| | | | llvm-svn: 339896
* [MC][X86] Enhance X86 Register expression handling to more closely match GCC.Nirav Dave2018-08-164-21/+39
| | | | | | | | | | | | | | | | Allow the comparison of x86 registers in the evaluation of assembler directives. This generalizes and simplifies the extension from r334022 to catch another case found in the Linux kernel. Reviewers: rnk, void Reviewed By: rnk Subscribers: hiraditya, nickdesaulniers, llvm-commits Differential Revision: https://reviews.llvm.org/D50795 llvm-svn: 339895
* Fix -Wmicrosoft-goto warnings.Zachary Turner2018-08-161-7/+13
| | | | llvm-svn: 339894
* Add support for AVX-512 CodeView registers.Zachary Turner2018-08-161-114/+170
| | | | | | | | | | | When compiling with /arch:AVX512 and optimizations turned on, we could crash while emitting debug info because we did not have CodeView register constants for the AVX 512 register set defined. This patch defines them. Differential Revision: https://reviews.llvm.org/D50819 llvm-svn: 339893
* [MS Demangler] Demangle string literals.Zachary Turner2018-08-161-3/+398
| | | | | | | | | | | | | | | | | | | | When demangling string literals, Microsoft's undname simply prints 'string'. This patch implements string literal demangling while doing a bit better than this by decoding as much of the string as possible and trying to faithfully reproduce the original string literal definition. This is a bit tricky because the different character types char, char16_t, and char32_t are not uniquely identified by the mangling, so we have to use a heuristic to try to guess the character type. But it works pretty well, and many tests are added to illustrate the behavior. Differential Revision: https://reviews.llvm.org/D50806 llvm-svn: 339892
* [MS Demangler] Don't fail on MD5-mangled names.Zachary Turner2018-08-161-1/+14
| | | | | | | | When we have an MD5 mangled name, we shouldn't choke and say that it's an invalid name. Even though it's impossible to demangle, we should just output the original name. llvm-svn: 339891
* [InstCombine] Expand the simplification of pow(x, 0.5) to sqrt(x)Evandro Menezes2018-08-161-31/+20
| | | | | | | | | Expand the number of cases when `pow(x, 0.5)` is simplified into `sqrt(x)` by considering the math semantics with more granularity. Differential revision: https://reviews.llvm.org/D50036 llvm-svn: 339887
* [InstCombine] move vector compare before same-shuffled opsSanjay Patel2018-08-161-0/+28
| | | | | | | This is a step towards fixing PR37463: https://bugs.llvm.org/show_bug.cgi?id=37463 llvm-svn: 339875
* [ARM] Ignore GEPs in ARMCodeGenPrepareSam Parker2018-08-161-0/+5
| | | | | | | | | | | While searching through the use-def tree, ignore GetElementPtrInst instructions because they don't need promoting and neither do their indices. Otherwise, the wide indices prevent the transformation from happening. Differential Revision: https://reviews.llvm.org/D50762 llvm-svn: 339871
* [ARM] Allow zext in ARMCodeGenPrepareSam Parker2018-08-161-3/+8
| | | | | | | | Treat zext instructions as roots, like we do for truncs. Differential Revision: https://reviews.llvm.org/D50759 llvm-svn: 339868
* [RISCV][MC] Don't fold symbol differences if ↵Alex Bradbury2018-08-161-4/+7
| | | | | | | | | | | | | | | | | | | | | | requiresDiffExpressionRelocations is true When emitting the difference between two symbols, the standard behavior is that the difference will be resolved to an absolute value if both of the symbols are offsets from the same data fragment. This is undesirable on architectures such as RISC-V where relaxation in the linker may cause the computed difference to become invalid. This caused an issue when compiling to object code, where the size of a function in the debug information was already calculated even though it could change as a consequence of relaxation in the subsequent linking stage. This patch inhibits the resolution of symbol differences to absolute values where the target's AsmBackend has declared that it does not want these to be folded. Differential Revision: https://reviews.llvm.org/D45773 Patch by Edward Jones. llvm-svn: 339864
* [ADT] Replace APInt::WORD_MAX with APInt::WORDTYPE_MAXSimon Pilgrim2018-08-161-9/+9
| | | | | | | | | | | | The windows SDK defines WORD_MAX, so any poor soul that wants to use LLVM in a project that depends on the windows SDK gets a build error. Given that it actually describes the maximal value of WordType, it actually fits even better than WORD_MAX Patch by: @miscco Differential Revision: https://reviews.llvm.org/D50777 llvm-svn: 339863
* [ARM] Allow signed icmps in ARMCodeGenPrepareSam Parker2018-08-161-30/+45
| | | | | | | | | | | | | | | | | Originally committed in r339755 which was reverted in r339806 due to an asan issue. The issue was caused by my assumption that operands to a CallInst mapped to the FunctionType Params. CallInsts are now handled by iterating over their ArgOperands instead of Operands. Original Message: Treat signed icmps as 'sinks', allowing them to be in the use-def tree, enabling more promotions to be performed. As a sink, any promoted incoming values need to be truncated before being used by the signed icmp. Differential Revision: https://reviews.llvm.org/D50067 llvm-svn: 339858
* [mips] Remove dead code from MipsPassConfigSimon Atanasyan2018-08-161-4/+0
| | | | | | | | | | Found by GCC's -Wunused-function. Patch by Kim Gräsman. Differential revision: https://reviews.llvm.org/D50612 llvm-svn: 339847
* [NFC] Remove const modifier to allow further development in LICMMax Kazantsev2018-08-161-3/+2
| | | | llvm-svn: 339846
* [NFC] Add missing const modifierMax Kazantsev2018-08-161-1/+1
| | | | llvm-svn: 339844
* [X86] Remove masking from the 512-bit padds and psubs intrinsics. Use select ↵Craig Topper2018-08-163-45/+27
| | | | | | in IR instead. llvm-svn: 339842
* [X86] Remove the unused masked 128 and 256-bit masked padds/psubs intrinsics.Craig Topper2018-08-162-20/+42
| | | | | | Still need to remove masking from the 512-bit versions. llvm-svn: 339841
* [x86] Actually initialize the SLH pass with the x86 backend and useChandler Carruth2018-08-162-3/+5
| | | | | | | | | | | | | | | a shorter name ('x86-slh') for the internal flags and pass name. Without this, you can't use the -stop-after or -stop-before infrastructure. I seem to have just missed this when originally adding the pass. The shorter name solves two problems. First, the flag names were ... really long and hard to type/manage. Second, the pass name can't be the exact same as the flag name used to enable this, and there are already some users of that flag name so I'm avoiding changing it unnecessarily. llvm-svn: 339836
* [BFI] Use rounding while computing profile counts.Easwaran Raman2018-08-161-1/+3
| | | | | | | | | | | | | | | Summary: Profile count of a block is computed by multiplying its block frequency by entry count and dividing the result by entry block frequency. Do rounded division in the last step and update test cases appropriately. Reviewers: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50822 llvm-svn: 339835
OpenPOWER on IntegriCloud