summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix typo. NFCISimon Pilgrim2019-09-071-1/+1
| | | | llvm-svn: 371317
* [mips] Follow-up to r371313 - fix failed test case. NFCSimon Atanasyan2019-09-071-1/+1
| | | | llvm-svn: 371316
* [X86] Avoid uses of getZextValue(). NFCI.Simon Pilgrim2019-09-071-22/+19
| | | | | | | | Use getAPIntValue() directly - this is mainly a best practice style issue to help prevent fuzz tests blowing up when a i12345 (or whatever) is generated. Use getConstantOperandVal/getConstantOperandAPInt wrappers where possible. llvm-svn: 371315
* [X86][AVX] Add 'f5' v4f64 shuffle test mentioned in D66004Simon Pilgrim2019-09-071-0/+32
| | | | llvm-svn: 371314
* [mips] Make another set of test cases more tolerant to exact symbol ↵Simon Atanasyan2019-09-0716-356/+251
| | | | | | addresses. NFC llvm-svn: 371313
* [ELF][MC] Set types of aliases of IFunc to STT_GNU_IFUNCFangrui Song2019-09-072-0/+47
| | | | | | | | | | | | | | | | | | ``` .type foo,@gnu_indirect_function .set foo,foo_resolver .set foo2,foo .set foo3,foo2 ``` The types of foo2 and foo3 should be STT_GNU_IFUNC, but we currently resolve them to the type of foo_resolver. This patch fixes it. Differential Revision: https://reviews.llvm.org/D67206 Patch by Senran Zhang llvm-svn: 371312
* [SimplifyCFG][NFC] Autogenerate PhiEliminate3.llRoman Lebedev2019-09-071-22/+71
| | | | llvm-svn: 371311
* [SimplifyCFG][NFC] Autogenerate two testsRoman Lebedev2019-09-072-26/+89
| | | | llvm-svn: 371310
* [CodeGen] Handle SMULFIXSAT with scale zero in ↵Bjorn Pettersson2019-09-072-10/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TargetLowering::expandFixedPointMul Summary: Normally TargetLowering::expandFixedPointMul would handle SMULFIXSAT with scale zero by using an SMULO to compute the product and determine if saturation is needed (if overflow happened). But if SMULO isn't custom/legal it falls through and uses the same technique, using MULHS/SMUL_LOHI, as used for non-zero scales. Problem was that when checking for overflow (handling saturation) when not using MULO we did not expect to find a zero scale. So we ended up in an assertion when doing APInt::getLowBitsSet(VTSize, Scale - 1) This patch fixes the problem by adding a new special case for how saturation is computed when scale is zero. Reviewers: RKSimon, bevinh, leonardchan, spatel Reviewed By: RKSimon Subscribers: wuzish, nemanjai, hiraditya, MaskRay, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67071 llvm-svn: 371309
* [Intrinsic] Add the llvm.umul.fix.sat intrinsicBjorn Pettersson2019-09-0722-50/+919
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an intrinsic that takes 2 unsigned integers with the scale of them provided as the third argument and performs fixed point multiplication on them. The result is saturated and clamped between the largest and smallest representable values of the first 2 operands. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Patch by: leonardchan, bjope Reviewers: RKSimon, craig.topper, bevinh, leonardchan, lebedev.ri, spatel Reviewed By: leonardchan Subscribers: ychen, wuzish, nemanjai, MaskRay, jsji, jdoerfert, Ka-Ka, hiraditya, rjmccall, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57836 llvm-svn: 371308
* [X86] Fix pshuflw formation from repeated shuffle mask (PR43230)Nikita Popov2019-09-072-19/+10
| | | | | | | | | | | | Fix for https://bugs.llvm.org/show_bug.cgi?id=43230. When creating PSHUFLW from a repeated shuffle mask, we have to apply the checks to the repeated mask, not the original one. For the test case from PR43230 the inspected part of the original mask is all undef. Differential Revision: https://reviews.llvm.org/D67314 llvm-svn: 371307
* [LVI] Look through extractvalue of insertvalueNikita Popov2019-09-072-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | This addresses the issue mentioned on D19867. When we simplify with.overflow instructions in CVP, we leave behind extractvalue of insertvalue sequences that LVI no longer understands. This means that we can not simplify any instructions based on the with.overflow anymore (until some over pass like InstCombine cleans them up). This patch extends LVI extractvalue handling by calling SimplifyExtractValueInst (which doesn't do anything more than constant folding + looking through insertvalue) and using the block value of the simplification. A possible alternative would be to do something similar to SimplifyIndVars, where we instead directly try to replace extractvalue users of the with.overflow. This would need some additional structural changes to CVP, as it's currently not legal to remove anything but the current instruction -- we'd have to introduce a worklist with instructions scheduled for deletion or similar. Differential Revision: https://reviews.llvm.org/D67035 llvm-svn: 371306
* [X86] Add test for PR43230; NFCNikita Popov2019-09-071-0/+50
| | | | llvm-svn: 371305
* [DwarfExpression] Disallow some rewrites to avoid undefined behaviorBjorn Pettersson2019-09-074-47/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The value operand in DW_OP_plus_uconst/DW_OP_constu value can be large (it uses uint64_t as representation internally in LLVM). This means that in the uint64_t to int conversions, previously done by DwarfExpression::addMachineRegExpression, could lose information. Also, the negation done in "-Offset" was undefined behavior in case Offset was exactly INT_MIN. To avoid the above problems, we now avoid transformation like [Reg, DW_OP_plus_uconst, Offset] --> [DW_OP_breg, Offset] and [Reg, DW_OP_constu, Offset, DW_OP_plus] --> [DW_OP_breg, Offset] when Offset > INT_MAX. And we avoid to transform [Reg, DW_OP_constu, Offset, DW_OP_minus] --> [DW_OP_breg,-Offset] when Offset > INT_MAX+1. The patch also adjusts DwarfCompileUnit::constructVariableDIEImpl to make sure that "DW_OP_constu, Offset, DW_OP_minus" is used instead of "DW_OP_plus_uconst, Offset" when creating DIExpressions with negative frame index offsets. Notice that this might just be the tip of the iceberg. There are lots of fishy handling related to these constants. I think both DIExpression::appendOffset and DIExpression::extractIfOffset may trigger undefined behavior for certain values. Reviewers: sdesmalen, rnk, JDevlieghere Reviewed By: JDevlieghere Subscribers: jholewinski, aprantl, hiraditya, ychen, uabelho, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D67263 llvm-svn: 371304
* [DebugInfo] Pre-commit of test case for DW_OP_breg/DW_OP_fbreg foldsBjorn Pettersson2019-09-071-0/+280
| | | | | | | | | | | This currently triggers undefined behavior if executed with an ubsan build. It is just a precommit of the test case to show that we got a problem. Fix is proposed in https://reviews.llvm.org/D67263 and plan is to commit the fix directly after this patch. llvm-svn: 371303
* Fix MSVC "32-bit shift implicitly converted to 64 bits" warnings. NFCI.Simon Pilgrim2019-09-072-2/+2
| | | | llvm-svn: 371302
* [SimplifyCFG][NFC] Make merge-cond-stores-cost.ll X86-specific, and rewrite itRoman Lebedev2019-09-072-37/+51
| | | | | | We clearly perform store-merging, even though div is really costly. llvm-svn: 371300
* [ELF][test] Improve testsFangrui Song2019-09-0733-360/+205
| | | | | | | | | | | | | | Add file-level comments Delete insignificant addresses to make them more tolerant to layout changes Simplify test output Delete weak-undef-val.s - covered by relocation-undefined-weak.s Delete weak-undef-export.s - covered by additional test added to weak-undef.s Delete version-undef-sym.s - covered by undefined-versioned-symbol.s => version-symbol-undef.s Delete symbol-ordering-file2.s - covered by symbol-ordering-file.s Delete gotpcrelx.s - covered by gotpc-relax-und-dso.s => x86-64-gotpc-relax-und-dso.s llvm-svn: 371299
* [Attributor] Make unimplemented method pure virtual.Benjamin Kramer2019-09-071-3/+3
| | | | | | Otherwise the compiler mistakes it for a vtable anchor. llvm-svn: 371298
* [SimplifyCFG][NFC] Show that we don't consider the cost when merging cond storesRoman Lebedev2019-09-071-0/+36
| | | | | | We count instruction count in each BB's separately, not their cost. llvm-svn: 371297
* [SimplifyCFG][NFC] Regenerate merge-cond-stores* testsRoman Lebedev2019-09-072-54/+65
| | | | llvm-svn: 371296
* [SimplifyCFG] SpeculativelyExecuteBB(): It's SpeculatedInstructions, not ↵Roman Lebedev2019-09-071-7/+7
| | | | | | | | | SpeculationCost It counts the number of instructions we are ok speculating (at most 1 there), not their cost, so rename accordingly. llvm-svn: 371294
* Replicate the change "[Alignment][NFC] Use Align with ↵Sylvestre Ledru2019-09-071-1/+1
| | | | | | | | | TargetLowering::setMinFunctionAlignment" on AVR to avoid a breakage. See r371200 / https://reviews.llvm.org/D67229 llvm-svn: 371293
* [ELF][test] Improve LTO testsFangrui Song2019-09-0715-78/+85
| | | | | | | | Add file-level comments Delete insignificant addresses to make them more tolerant to layout changes Simplify test output llvm-svn: 371292
* [Attributor] ValueSimplify Abstract AttributeHideto Ueno2019-09-076-7/+418
| | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces initial `AAValueSimplify` which simplifies a value in a context. example - (for function returned) If all the return values are the same and constant, then we can replace callsite returned with the constant. - If an internal function takes the same value(constant) as an argument in the callsite, then we can replace the argument with that constant. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66967 llvm-svn: 371291
* [git-llvm] Do not reinvent `@{upstream}`David Zarzycki2019-09-071-12/+2
| | | | | | | | Make `git-llvm` more robust when used with a nontrivial repository. https://reviews.llvm.org/D67262 llvm-svn: 371290
* Revert [CodeGen] Fix typos to run tests. NFC.Xing GUO2019-09-071-2/+2
| | | | | | | | This reverts r371286 (git commit b38105bbd0f7dfef424a4f096aa6a6b7b467fe99) r371286 caused build bots' failure. I'll check it. llvm-svn: 371289
* [CodeGen] Fix typos to run tests. NFC.Xing GUO2019-09-071-2/+2
| | | | llvm-svn: 371286
* Remove stale TLI Module level pass registrationTeresa Johnson2019-09-071-1/+0
| | | | | | | | Clang patch to adapt to LLVM changes in D66428 that make the TLI require a Function. There is no longer a module-level TargetLibraryAnalysis, so remove its registration llvm-svn: 371285
* Change TargetLibraryInfo analysis passes to always require FunctionTeresa Johnson2019-09-0782-243/+398
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first change to enable the TLI to be built per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. This change should not affect behavior, as the provided function is not yet used to build a specifically per-function TLI, but rather enables that migration. Most of the changes were very mechanical, e.g. passing a Function to the legacy analysis pass's getTLI interface, or in Module level cases, adding a callback. This is similar to the way the per-function TTI analysis works. There was one place where we were looking for builtins but not in the context of a specific function. See FindCXAAtExit in lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround could provide the wrong behavior in some corner cases. Suggestions welcome. Reviewers: chandlerc, hfinkel Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66428 llvm-svn: 371284
* [X86] Add tests for fp128 frem, sqrt, sin, and cos.Craig Topper2019-09-071-0/+87
| | | | llvm-svn: 371283
* [X86] Autogenerate fp128-libcalls.llCraig Topper2019-09-071-40/+81
| | | | llvm-svn: 371282
* [llvm-objcopy] Rename SHOffset (e_shoff) field to SHOff. NFCFangrui Song2019-09-072-7/+7
| | | | | | | | | Similar to D67254. `struct Elf*_Shdr` has a field `sh_offset`. Rename SHOffset to SHOff to avoid confusion. llvm-svn: 371281
* Long timeouts for the MacOSX SystemRuntime plugins under ASAN; else quick.Jason Molenda2019-09-074-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | In April via r357829, Adrian unified timeouts across lldb and set the default value high so that we wouldn't get timeouts on ASAN bots that were running under load. The library that the MacOSX SystemRuntime has functions that need to take a lock, and if that lock is held already, those functions will never complete; we're seeing the 15 second timeout being hit with inferiors that are doing a lot of enqueuing and dequeuing of libdispatch work items causing this deadlocking behavior. This patch reverts to a very short timeout for these SystemRuntime function calls, given the behavior of this library that they are calling into. When lldb is built with AddressSanitizer enabled, they will use the default 15 second timeout. tl;dr: this reverts to the previous timeouts for these SystemRuntime inf func calls. <rdar://problem/54538149> llvm-svn: 371280
* [clang][DependencyFileGenerator] Fix missing -MT option handlingJan Korous2019-09-072-5/+5
| | | | | | | | Targets in DependencyFileGenerator don't necessarily come from -MT option. Differential Revision: https://reviews.llvm.org/D67308 llvm-svn: 371279
* Fix thunks.cpp test, don't FileCheck for anon namespace idReid Kleckner2019-09-071-1/+1
| | | | | | | The anon namespace id is a hash of the main input path to the compiler, which varies in the test suite because the input path is absolute. llvm-svn: 371277
* [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownershipAkira Hatanaka2019-09-077-53/+87
| | | | | | | | | | | | | | | | | qualifications as unavailable if the union is declared in a system header r365985 stopped marking those fields as unavailable, which caused the union's NonTrivialToPrimitive* bits to be set to true. This patch restores the behavior prior to r365985, except that users can explicitly specify the ownership qualification of the field to instruct the compiler not to mark it as unavailable. rdar://problem/53420753 Differential Revision: https://reviews.llvm.org/D65256 llvm-svn: 371276
* [Sema] Diagnose default-initialization, destruction, and copying ofAkira Hatanaka2019-09-0718-122/+615
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-trivial C union types This recommits r365985, which was reverted because it broke a few projects using unions containing non-trivial ObjC pointer fields in system headers. We now have a patch to fix the problem (see https://reviews.llvm.org/D65256). Original commit message: This patch diagnoses uses of non-trivial C unions and structs/unions containing non-trivial C unions in the following contexts, which require default-initialization, destruction, or copying of the union objects, instead of disallowing fields of non-trivial types in C unions, which is what we currently do: - function parameters. - function returns. - assignments. - compound literals. - block captures except capturing of `__block` variables by non-escaping blocks. - local and global variable definitions. - lvalue-to-rvalue conversions of volatile types. See the discussion in https://reviews.llvm.org/D62988 for more background. rdar://problem/50679094 Differential Revision: https://reviews.llvm.org/D63753 llvm-svn: 371275
* Synchronize LLVM's copy of libc++abi's demangler with the libc++abiRichard Smith2019-09-073-30/+420
| | | | | | | | | version after r371273. Also fix a minor issue in r371273 that only surfaced after template instantiation from LLVM's use of the demangler. llvm-svn: 371274
* Implement demangling support for C++20 lambda expression extensions.Richard Smith2019-09-063-31/+429
| | | | | | | | | | | | | | | | | | | | | | | | | This implements demangling support for the mangling extensions specified in https://github.com/itanium-cxx-abi/cxx-abi/pull/85, much of which is implemented in Clang r359967 and r371004. Specifically, this provides demangling for: * <template-param-decl> in <lambda-sig> * <template-param> with non-zero level * lambda-expression literals (not emitted by Clang yet) * nullptr literals * string literals (The final two seem unrelated, but handling them was necessary in order to disambiguate between lambda expressions and the other forms of literal for which we have a type but no value.) When demangling a <lambda-sig>, we form template parameters with no corresponding argument, so we cannot substitute in the argument in the demangling. Instead we invent synthetic names for the template parameters (eg, '[]<typename $T>($T *x)'). llvm-svn: 371273
* Use musttail for variadic method thunks when possibleReid Kleckner2019-09-064-19/+184
| | | | | | | | | | | | | | | | | | | | | This avoids cloning variadic virtual methods when the target supports musttail and the return type is not covariant. I think we never implemented this previously because it doesn't handle the covariant case. But, in the MS ABI, there are some cases where vtable thunks must be emitted even when the variadic method defintion is not available, so it looks like we need to implement this. Do it for both ABIs, since it's a nice size improvement and simplification for Itanium. Emit an error when emitting thunks for variadic methods with a covariant return type. This case is essentially not implementable unless the ABI provides a way to perfectly forward variadic arguments without a tail call. Fixes PR43173. Differential Revision: https://reviews.llvm.org/D67028 llvm-svn: 371269
* Update lld tests dynamic-list.s and symbol-override.s to use llvm-nmMatthew Voss2019-09-062-4/+4
| | | | | | | | | | The following tests failed on Windows bots due to nm not being available: lld/test/ELF/dynamic-list.s lld/test/ELF/symbol-override.s llvm-svn: 371267
* [AArch64][GlobalISel] Enable the localizer for optimized builds.Amara Emerson2019-09-064-8/+6
| | | | | | | | | | | | | | | | | | | Despite the fact that the localizer's original motivation was to fix horrendous constant spilling at -O0, shortening live ranges still has net benefits even with optimizations enabled. On an -Os build of CTMark, doing this improves code size by 0.5% geomean. There are a few regressions, bullet increasing in size by 0.5%. One example from bullet where code size increased slightly was due to GlobalISel actually now generating the same code as SelectionDAG. So we actually have an opportunity in future to implement better heuristics for localization and therefore be *better* than SDAG in some cases. In relation to other optimizations though that one is relatively minor. Differential Revision: https://reviews.llvm.org/D67303 llvm-svn: 371266
* [InstCombine] Refactor substitution of instruction in the parent BB (NFC)Evandro Menezes2019-09-062-14/+15
| | | | | | | | | Add the new method `LibCallSimplifier::substituteInParent()` that calls `LibCallSimplifier::replaceAllUsesWith()' and `LibCallSimplifier::eraseFromParent()` back to back, simplifying the resulting code. llvm-svn: 371264
* [ORC][RPC] Join server thread before checking condition in unit test.Lang Hames2019-09-061-2/+2
| | | | | | Otherwise we have a race on the sent-messages count. llvm-svn: 371263
* [IR] CallBrInst: scan+update arg list when indirect dest list changesNick Desaulniers2019-09-063-5/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There's an unspoken invariant of callbr that the list of BlockAddress Constants in the "function args" list match the BasicBlocks in the "other labels" list. (This invariant is being added to the LangRef in https://reviews.llvm.org/D67196). When modifying the any of the indirect destinations of a callbr instruction (possible jump targets), we need to update the function arguments if the argument is a BlockAddress whose BasicBlock refers to the indirect destination BasicBlock being replaced. Otherwise, many transforms that modify successors will end up violating that invariant. A recent change to the arm64 Linux kernel exposed this bug, which prevents the kernel from booting. I considered maintaining a mapping from indirect destination BasicBlock to argument operand BlockAddress, but this ends up being a one to potentially many (though usually one) mapping. Also, the list of arguments to a function (or more typically inline assembly) ends up being less than 10. The implementation is significantly simpler to just rescan the full list of arguments. Because of the one to potentially many relationship, the full arg list must be scanned (we can't stop at the first instance). Thanks to the following folks that reported the issue and helped debug it: * Nathan Chancellor * Will Deacon * Andrew Murray * Craig Topper Link: https://bugs.llvm.org/show_bug.cgi?id=43222 Link: https://github.com/ClangBuiltLinux/linux/issues/649 Link: https://lists.infradead.org/pipermail/linux-arm-kernel/2019-September/678330.html Reviewers: craig.topper, chandlerc Reviewed By: craig.topper Subscribers: void, javed.absar, kristof.beyls, hiraditya, llvm-commits, nathanchance, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D67252 llvm-svn: 371262
* [X86] Add a AVX512VBMI command line to min-legal-vector-width.ll. Always ↵Craig Topper2019-09-061-73/+129
| | | | | | | | | | | | | | | enable fast-variable-shuffle Trying to minimize the features we need to manipulate when this is updated for D67259. The VBMI is interesting because it enables some improved combining for truncates. I enabled fast-variable-shuffle because all the CPUs we're going to add implicitly enable it. So they can share check lines. llvm-svn: 371261
* [X86] Replace -mcpu with -mattr on some tests.Craig Topper2019-09-062-5/+4
| | | | llvm-svn: 371260
* [test] Add a FIXME test for stop-command-source-on-errorJonas Devlieghere2019-09-063-0/+30
| | | | | | | | | | | | | | Modifying the interpreter settings is tricky because they don't take effect until we create a new command interpreter, which should be merely an implementation detail. This leads to confusing and unexpected scenarios. This adds a test cases with FIXMEs for some of the odd scenarios I encountered. I didn't XFAIL the test because I don't think there's a way to get an unexpected PASS if any of the commands succeeds and splitting up the file in multiple tests seems excessive. llvm-svn: 371259
* [Core] Remove use of ClangASTContext in DumpDataExtractorAlex Langford2019-09-064-52/+49
| | | | | | | | | | | | | Summary: DumpDataExtractor uses ClangASTContext in order to get the proper llvm fltSemantics for the type it needs so that it can dump floats in a more precise way. However, there's no reason that this behavior needs to be specific ClangASTContext. Instead, I think it makes sense to ask TypeSystems for the float semantics for a type of a given size. Differential Revision: https://reviews.llvm.org/D67239 llvm-svn: 371258
OpenPOWER on IntegriCloud