summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [NFC] Factor out guard utility methods into a separate fileMax Kazantsev2018-08-293-48/+67
| | | | | | | | | | This patch creates file GuardUtils which will contain logic for work with guards that can be shared across different passes. Differential Revision: https://reviews.llvm.org/D51151 Reviewed By: fedor.sergeev llvm-svn: 340914
* [X86][AVX] Prefer VPBLENDW+VPBLENDD to VPBLENDVB for v16i16 blend shufflesSimon Pilgrim2018-08-291-2/+14
| | | | | | | | | | Noticed while looking at D49562 codegen - we can avoid a large constant mask load and a slow VPBLENDVB select op by using VPBLENDW+VPBLENDD instead. TODO: As discussed on the patch, we should investigate adding VPBLENDVB handling to target shuffle combining as well, that will allow us to extend this to VPBLENDW+VPBLENDW+VPBLENDD. Differential Revision: https://reviews.llvm.org/D50074 llvm-svn: 340913
* [MC] fix a clang-tidy warning, NFCKrasimir Georgiev2018-08-291-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: Per clang-tidy: function 'llvm::MCStreamer::checkCVLocSection' has a definition with different parameter names .../llvm/lib/MC/MCStreamer.cpp:275:18: the definition seen here .../llvm/include/llvm/MC/MCStreamer.h:235:8: differing parameters are named here: ('FuncId'), in definition: ('FunctionId') Reviewers: bkramer Reviewed By: bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51406 llvm-svn: 340912
* Revert r340904 "[llvm-mc] - Allow to set custom flags for debug sections."George Rimar2018-08-292-15/+4
| | | | | | | It broke PPC64 BB: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/23252 llvm-svn: 340906
* [llvm-mc] - Allow to set custom flags for debug sections.George Rimar2018-08-292-4/+15
| | | | | | | | | | | | | | | | | | | | | | I am experimenting with a single split dwarf (.dwo sections in .o files). I want to make linker to ignore .dwo sections in .o, for that I am trying to add SHF_EXCLUDE flag ("E") for them in my asm sample. I found that currently, it is impossible to add any flag for debug sections using llvm-mc. That happens because we have a set of predefined unique sections created early with default flags: https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCObjectFileInfo.cpp#L391 This patch allows a user to add any flags he wants. I had to edit TargetLoweringObjectFileImpl.cpp to set MetaData type for debug sections. Their kind was Data by default (so they were allocatable) and so after changes introduced by this patch the SHF_ALLOC flag was applied for them, what does not make sense for debug sections. One of OrcJITTests tests failed because of that. Differential revision: https://reviews.llvm.org/D51361 llvm-svn: 340904
* AMDGPU: Fix getInstSizeInBytesNicolai Haehnle2018-08-294-34/+45
| | | | | | | | | | | | | | | | | | | | | | | Summary: Add some optional code to validate getInstSizeInBytes for emitted instructions. This flushed out some issues which are fixed by this patch: - Streamline getInstSizeInBytes - Properly define the VI readlane/writelane instruction as VOP3 - Fix the inline constant determination. Specifically, this change fixes an issue where a 32-bit value of 0xffffffff was recorded as unsigned. This is equal to -1 when restricting to a 32-bit comparison, and an inline constant can be used. Reviewers: arsenm, rampitec Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D50629 Change-Id: Id87c3b7975839da0de8156a124b0ce98c5fb47f2 llvm-svn: 340903
* LoopSink: Don't sink into blocks without an insertion point (PR38462)Hans Wennborg2018-08-291-0/+8
| | | | | | | | | In the PR, LoopSink was trying to sink into a catchswitch block, which doesn't have a valid insertion point. Differential Revision: https://reviews.llvm.org/D51307 llvm-svn: 340900
* Add support for various C++14 demanglings.Zachary Turner2018-08-293-24/+54
| | | | | | | | | | Mostly this includes <auto> and <decltype-auto> return values. Additionally, this fixes a fairly obscure back-referencing bug that was encountered in one of the C++14 tests, which is that if you have something like Foo<&bar, &bar> then the `bar` forms a backreference. llvm-svn: 340896
* [MS Demangler] Add output flags to all function calls.Zachary Turner2018-08-293-138/+138
| | | | | | | | | | | | Previously we had a FunctionSigFlags, but it's more flexible to just have one set of output flags that apply to the entire process and just pipe the entire set of flags through the output process. This will be useful when we start allowing the user to customize the outputting behavior. llvm-svn: 340894
* [GISel]: Add legalization support for Widening UADDO/USUBOAditya Nandakumar2018-08-291-0/+26
| | | | | | | | | | | https://reviews.llvm.org/D51384 Added code in LegalizerHelper to widen UADDO/USUBO along with unit tests. Reviewed by volkan. llvm-svn: 340892
* [X86] Support v2i32 gather/scatter indices with ↵Craig Topper2018-08-293-21/+46
| | | | | | | | | | | | | | | | -x86-experimental-vector-widening-legalization Summary: This is split out from D41062 to cover the code in LegalVectorTypes.cpp Reviewers: RKSimon, spatel, efriedma Reviewed By: efriedma Subscribers: sdardis, jvesely, nhaehnle, jrtc27, atanasyan, llvm-commits Differential Revision: https://reviews.llvm.org/D51337 llvm-svn: 340891
* Start reserving x18 by default on Android targets.Peter Collingbourne2018-08-291-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D45588 llvm-svn: 340889
* [codeview] Clean up machinery for deferring .cv_loc emissionReid Kleckner2018-08-285-76/+53
| | | | | | | | | | | Now that we create the label at the point of the directive, we don't need to set the "current CV location", and then later when we emit the next instruction, create a label for it and emit it. DWARF still defers the labels used in .debug_loc until the next instruction or value, for reasons unknown. llvm-svn: 340883
* [QTOOL-37352] Consider isLegalAddressingImm in Constant HoistingZhaoshi Zheng2018-08-281-1/+21
| | | | | | | | | | | | | | In Thumb1, legal imm range is [0, 255] for ADD/SUB instructions. However, the legal imm range for LD/ST in (R+Imm) addressing mode is [0, 127]. Imms in [128, 255] are materialized by mov R, #imm, and LD/STs use them in (R+R) addressing mode. This patch checks if a constant is used as offset in (R+Imm), if so, it checks isLegalAddressingMode passing the constant value as BaseOffset. Differential Revision: https://reviews.llvm.org/D50931 llvm-svn: 340882
* [codeview] Emit labels for .cv_loc immediatelyReid Kleckner2018-08-281-4/+4
| | | | | | | | | | | | | | | Previously we followed the DWARF implementation, which waits until the next instruction or data to emit the label to use in the .debug_loc section. We might want to consider re-evaluating that design choice as well, since it means the .loc skips alignment padding, for better or worse. This was the most minimal fix I could come up with, but we should be able to do a lot of cleanups now that we don't need to save a pending CV location on the CodeViewContext. I plan to do those next, but this immediately fixes an assertion for some of our users. llvm-svn: 340878
* [ORC] Replace lookupFlags in JITSymbolResolver with getResponsibilitySet.Lang Hames2018-08-287-74/+69
| | | | | | | | | | | | | | The new method name/behavior more closely models the way it was being used. It also fixes an assertion that can occur when using the new ORC Core APIs, where flags alone don't necessarily provide enough context to decide whether the caller is responsible for materializing a given symbol (which was always the reason this API existed). The default implementation of getResponsibilitySet uses lookupFlags to determine responsibility as before, so existing JITSymbolResolvers should continue to work. llvm-svn: 340874
* [NFC][PassTiming] factor out generic PassTimingInfoFedor Sergeev2018-08-286-96/+137
| | | | | | | | Moving PassTimingInfo from legacy pass manager code into a separate header. Making it suitable for both legacy and new pass manager. Adding a test on -time-passes main functionality. llvm-svn: 340872
* [SimpleLoopUnswitch] Form dedicated exits after trivial unswitches.Alina Sbirlea2018-08-281-5/+8
| | | | | | | | | | | | | | Summary: Form dedicated exits after trivial unswitches. Fixes PR38737, PR38283. Reviewers: chandlerc, fedor.sergeev Subscribers: sanjoy, jlebar, uabelho, llvm-commits Differential Revision: https://reviews.llvm.org/D51375 llvm-svn: 340871
* [ORC] Add an addObjectFile method to LLJIT.Lang Hames2018-08-281-0/+7
| | | | | | | | | | The addObjectFile method adds the given object file to the JIT session, making its code available for execution. Support for the -extra-object flag is added to lli when operating in -jit-kind=orc-lazy mode to support testing of this feature. llvm-svn: 340870
* [X86] Add intrinsics for KADD instructionsCraig Topper2018-08-281-0/+4
| | | | | | | | | | These are intrinsics for supporting kadd builtins in clang. These builtins are already in gcc to implement intrinsics from icc. Though they are missing from the Intel Intrinsics Guide. This instruction adds two mask registers together as if they were scalar rather than a vXi1. We might be able to get away with a bitcast to scalar and a normal add instruction, but that would require DAG combine smarts in the backend to recoqnize add+bitcast. For now I'd prefer to go with the easiest implementation so we can get these builtins in to clang with good codegen. Differential Revision: https://reviews.llvm.org/D51370 llvm-svn: 340869
* [AMDGPU] Fix -Wunused-variable when -DLLVM_ENABLE_ASSERTIONS=offFangrui Song2018-08-281-2/+1
| | | | llvm-svn: 340868
* Revert "[libFuzzer] Port to Windows"Matt Morehouse2018-08-281-23/+6
| | | | | | This reverts commit r340860 due to failing tests. llvm-svn: 340867
* AMDGPU: Don't delete instructions if S_ENDPGM has implicit usesMatt Arsenault2018-08-281-1/+8
| | | | | | | | This can leave behind the uses with the defs removed. Since this should only really happen in tests, it's not worth the effort of trying to handle this. llvm-svn: 340866
* [GISel]: Add missing opcodes for overflow intrinsicsAditya Nandakumar2018-08-281-13/+7
| | | | | | | | | | | | | | | | https://reviews.llvm.org/D51197 Currently, IRTranslator (and GISel) seems to be arbitrarily picking which overflow intrinsics get mapped into opcodes which either have a carry as an input or not. For intrinsics such as Intrinsic::uadd_with_overflow, translate it to an opcode (G_UADDO) which doesn't have any carry inputs (similar to LLVM IR). This patch adds 4 missing opcodes for completeness - G_UADDO, G_USUBO, G_SSUBE and G_SADDE. llvm-svn: 340865
* [WebAssembly][NFC] Document stackifier tablegen backendThomas Lively2018-08-281-2/+7
| | | | | | | | | | | | | | Summary: Add comments to help readers avoid having to read tablegen backends to understand the code. Also remove unecessary breaks from the output. Reviewers: dschuff, aheejin Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51371 llvm-svn: 340864
* AMDGPU: Force shrinking of add/sub even if the carry is usedMatt Arsenault2018-08-281-5/+8
| | | | | | | | | The original motivating example uses a 64-bit add, so the carry is used. Insert a copy from VCC. This may allow shrinking of the used carry instruction. At worst, we are replacing a mov to materialize the constant with a copy of vcc. llvm-svn: 340862
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-281-6/+23
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340860
* AMDGPU: Shrink insts to fold immediatesMatt Arsenault2018-08-284-54/+138
| | | | | | | | | This needs to be done in the SSA fold operands pass to be effective, so there is a bit of overlap with SIShrinkInstructions but I don't think this is practically avoidable. llvm-svn: 340859
* [WebAssembly] v128.notThomas Lively2018-08-281-0/+17
| | | | | | Implementation and tests. llvm-svn: 340857
* AMDGPU: Move canShrink into TIIMatt Arsenault2018-08-283-56/+57
| | | | llvm-svn: 340855
* [DAGCombine] Rework MERGE_VALUES to inline in single pass. NFCI.Nirav Dave2018-08-281-1/+4
| | | | | | | Avoid hyperlinear cost of inlining MERGE_VALUE node by constructing temporary vector and doing a single replacement. llvm-svn: 340853
* [DAG] Avoid recomputing Divergence checks. NFCI.Nirav Dave2018-08-281-6/+10
| | | | | | | When making multiple updates to the same SDNode, recompute node divergence only once after all changes have been made. llvm-svn: 340852
* [DAG] Fix updateDivergence calculationNirav Dave2018-08-281-1/+1
| | | | | | | Check correct SDNode when deciding if we should update the divergence property. llvm-svn: 340851
* AMDGPU: Remove nan tests in class if src is nnanMatt Arsenault2018-08-281-0/+7
| | | | llvm-svn: 340850
* [WebAssembly] Use getCalleeOpNo utility function (NFC)Heejin Ahn2018-08-281-14/+2
| | | | | | | | | | Reviewers: tlively Subscribers: dschuff, sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51366 llvm-svn: 340848
* [X86] Mark the FUCOMI instructions as requiring CMOV to be enabled. NFCICraig Topper2018-08-281-0/+3
| | | | | | | | These instructions were added on the PentiumPro along with CMOV. This was already comprehended by the lowering process which should emit an alternate sequence using FCOM and FNSTW. This just makes it an explicit error if that doesn't work for some reason. llvm-svn: 340844
* [debuginfo] generate debug info with asm+.fileBrian Cain2018-08-281-8/+8
| | | | | | | | | | | | | | | Summary: For assembly input files, generate debug info even when the .file directive is present, provided it does not include a file-number argument. Fixes PR38695. Reviewers: probinson, sidneym Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D51315 llvm-svn: 340839
* [Inliner] Attribute callsites with inline remarksDavid Bolvansky2018-08-281-10/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Sometimes reading an output *.ll file it is not easy to understand why some callsites are not inlined. We can read output of inline remarks (option --pass-remarks-missed=inline) and try correlating its messages with the callsites. An easier way proposed by this patch is to add to every callsite processed by Inliner an attribute with the latest message that describes the cause of not inlining this callsite. The attribute is called //inline-remark//. By default this feature is off. It can be switched on by the option //-inline-remark-attribute//. For example in the provided test the result method //@test1// has two callsites //@bar// and inline remarks report different inlining missed reasons: remark: <unknown>:0:0: bar not inlined into test1 because too costly to inline (cost=-5, threshold=-6) remark: <unknown>:0:0: bar not inlined into test1 because it should never be inlined (cost=never): recursive It is not clear which remark correspond to which callsite. With the inline remark attribute enabled we get the reasons attached to their callsites: define void @test1() { call void @bar(i1 true) #0 call void @bar(i1 false) #2 ret void } attributes #0 = { "inline-remark"="(cost=-5, threshold=-6)" } .. attributes #2 = { "inline-remark"="(cost=never): recursive" } Patch by: yrouban (Yevgeny Rouban) Reviewers: xbolva00, tejohnson, apilipenko Reviewed By: xbolva00, tejohnson Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D50435 llvm-svn: 340834
* [AMDGPU] Add support for a16 modifiear for gfx9Ryan Taylor2018-08-289-45/+86
| | | | | | | | | | | | | Summary: Adding support for a16 for gfx9. A16 bit replaces r128 bit for gfx9. Change-Id: Ie8b881e4e6d2f023fb5e0150420893513e5f4841 Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50575 llvm-svn: 340831
* [CloneFunction] Constant fold terminators before checking single predecessorMikael Holmen2018-08-281-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes PR31105. There is code trying to delete dead code that does so by e.g. checking if the single predecessor of a block is the block itself. That check fails on a block like this bb: br i1 undef, label %bb, label %bb since that has two (identical) predecessors. However, after the check for dead blocks there is a call to ConstantFoldTerminator on the basic block, and that call simplifies the block to bb: br label %bb Therefore we now do the call to ConstantFoldTerminator before the check if the block is dead, so it can realize that it really is. The original behavior lead to the block not being removed, but it was simplified as above, and then we did a call to Dest->replaceAllUsesWith(&*I); with old and new being equal, and an assertion triggered. Reviewers: chandlerc, fhahn Reviewed By: fhahn Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D51280 llvm-svn: 340820
* [GVNHoist] Prune out useless CHI insertionsAlexandros Lamprineas2018-08-281-2/+5
| | | | | | | | | | Fix for the out-of-memory error when compiling SemaChecking.cpp with GVNHoist and ubsan enabled. I've used a cache for inserted CHIs to avoid excessive memory usage. Differential Revision: https://reviews.llvm.org/D50323 llvm-svn: 340818
* [X86][SSE] Improve variable scalar shift of vXi8 vectors (PR34694)Simon Pilgrim2018-08-281-13/+58
| | | | | | | | This patch creates the shift mask and actual shift using the vXi16 vector shift ops. Differential Revision: https://reviews.llvm.org/D51263 llvm-svn: 340813
* [X86][SSE] Avoid vector extraction/insertion for non-constant uniform shiftsSimon Pilgrim2018-08-281-6/+19
| | | | | | As discussed on D51263, we're better off using byte shifts to clear the upper bits on pre-SSE41 hardware. llvm-svn: 340810
* [NFC] A loop can never contain Ret instructionMax Kazantsev2018-08-281-1/+1
| | | | llvm-svn: 340808
* Fix in getAllocationDataForFunctionDavid Chisnall2018-08-281-1/+1
| | | | | | | | | | | | | | | | Summary: Correct to use set like behaviour of AllocType. Should check for subset, not precise value. Reviewers: theraven Reviewed By: theraven Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50959 llvm-svn: 340807
* [X86] Fix some comments to refer to KORTEST not KTEST. NFCCraig Topper2018-08-281-6/+6
| | | | | | KTEST is a different instruction. All of this code uses KORTEST. llvm-svn: 340799
* [DAGCombiner][AMDGPU][Mips] Fold bitcast with volatile loads if the ↵Craig Topper2018-08-281-3/+12
| | | | | | | | | | | | | | | | | | | resulting load is legal for the target. Summary: I'm not sure if this patch is correct or if it needs more qualifying somehow. Bitcast shouldn't change the size of the load so it should be ok? We already do something similar for stores. We'll change the type of a volatile store if the resulting store is Legal or Custom. I'm not sure we should be allowing Custom there... I was playing around with converting X86 atomic loads/stores(except seq_cst) into regular volatile loads and stores during lowering. This would allow some special RMW isel patterns in X86InstrCompiler.td to be removed. But there's some floating point patterns in there that didn't work because we don't fold (f64 (bitconvert (i64 volatile load))) or (f32 (bitconvert (i32 volatile load))). Reviewers: efriedma, atanasyan, arsenm Reviewed By: efriedma Subscribers: jvesely, arsenm, sdardis, kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, arichardson, jrtc27, atanasyan, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50491 llvm-svn: 340797
* [InstCombine] Extend (add (sext x), cst) --> (sext (add x, cst')) and (add ↵Craig Topper2018-08-281-2/+4
| | | | | | | | (zext x), cst) --> (zext (add x, cst')) to work for vectors Differential Revision: https://reviews.llvm.org/D51236 llvm-svn: 340796
* [PPC] Remove Darwin support from POWER backend.Kit Barton2018-08-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch issues an error message if Darwin ABI is attempted with the PPC backend. It also cleans up existing test cases, either converting the test to use an alternative triple or removing the test if the coverage is no longer needed. Updated Tests ------------- The majority of test cases were updated to use a different triple that does not include the Darwin ABI. Many tests were also updated to use FileCheck, in place of grep. Deleted Tests ------------- llvm/test/tools/dsymutil/PowerPC/sibling.test was originally added to test specific functionality of dsymutil using an object file created with an old version of llvm-gcc for a Powerbook G4. After a discussion with @JDevlieghere he suggested removing the test. llvm/test/CodeGen/PowerPC/combine_loads_from_build_pair.ll was converted from a PPC test to a SystemZ test, as the behavior is also reproducible there. All other tests that were deleted were specific to the darwin/ppc ABI and no longer necessary. Phabricator Review: https://reviews.llvm.org/D50988 llvm-svn: 340795
* Revert "[CodeGenPrepare] Scan past debug intrinsics to find select ↵David Blaikie2018-08-281-4/+3
| | | | | | | | | | | | | | | candidates (NFC)" This causes crashes due to the interleaved dbg.value intrinsics being left at the end of basic blocks, causing the actual terminators (br, etc) to be not where they should be (not at the end of the block), leading to later crashes. Further discussion on the original commit thread. This reverts commit r340368. llvm-svn: 340794
OpenPOWER on IntegriCloud