summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [android/process list] support showing process argumentsWalter Erquinigo2019-10-168-126/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The qfProcessInfo and qsProcessInfo packets currently don't set the processes' arguments, however the platform process list -v command tries to print it. In this diff I'm adding the arguments as part of the packet, and now the command shows the arguments just like on mac. On Mac: 507 1 wallace 1876110778 wallace 1876110778 x86_64-apple-macosx /usr/libexec/secd 503 1 wallace 1876110778 wallace 1876110778 x86_64-apple-macosx /usr/libexec/secinitd 501 1 wallace 1876110778 wallace 1876110778 x86_64-apple-macosx /usr/libexec/languageassetd --firstLogin 497 1 wallace 1876110778 wallace 1876110778 x86_64-apple-macosx /usr/libexec/trustd --agent 496 1 wallace 1876110778 wallace 1876110778 x86_64-apple-macosx /usr/libexec/lsd 494 1 wallace 1876110778 wallace 1876110778 x86_64-apple-macosx /System/Library/Frameworks/CoreTelephony.framework/Support/CommCenter -L 491 1 wallace 1876110778 wallace 1876110778 x86_64-apple-macosx /usr/sbin/distnoted agent 489 1 wallace 1876110778 wallace 1876110778 x86_64-apple-macosx /usr/libexec/UserEventAgent (Aqua) 484 1 wallace 1876110778 wallace 1876110778 x86_64-apple-macosx /usr/sbin/cfprefsd agent 483 1 wallace 1876110778 wallace 1876110778 x86_64-apple-macosx /System/Library/Frameworks/LocalAuthentication.framework/Support/coreauthd On android: 1561 1016 root 0 0 aarch64-unknown-linux-android /system/bin/ip6tables-restore--noflush -w -v 1805 982 1000 1000 1000 android:drmService 1811 982 10189 10189 10189 com.qualcomm.embms:remote 1999 1 1000 1000 1000 aarch64-unknown-linux-android /system/bin/tlc_serverCCM 2332 982 10038 10038 10038 com.android.systemui 2378 983 1053 1053 1053 webview_zygote 2448 982 5013 5013 5013 com.sec.location.nsflp2 2465 982 10027 10027 10027 com.google.android.gms.persistent Differential Revision: https://reviews.llvm.org/D68293 llvm-svn: 375029
* [llvm-ar] Implement the V modifier as an alias for --versionJordan Rupprecht2019-10-163-1/+25
| | | | | | | | | | | | | | Summary: Also update the help modifier (h) so that it works as a modifier and not just as a standalone `h`. For example, `llvm-ar h` prints the help message, but `llvm-ar xh` currently prints `unknown option h`. Reviewers: MaskRay, gbreynoo Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69007 llvm-svn: 375028
* Fix darwin-ld-lto test for some speical pathSteven Wu2019-10-161-2/+4
| | | | | | | | | Fix the test by not assuming the prefix path of the temp directory can be matched by a regex. rdar://problem/56259195 llvm-svn: 375027
* [OPENMP]Allow priority clause in combined task-based directives.Alexey Bataev2019-10-168-28/+47
| | | | | | | The expression of the priority clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 375026
* [SLP] avoid reduction transform on patterns that the backend can ↵Sanjay Patel2019-10-162-52/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | load-combine (2nd try) The 1st attempt at this modified the cost model in a bad way to avoid the vectorization, but that caused problems for other users (the loop vectorizer) of the cost model. I don't see an ideal solution to these 2 related, potentially large, perf regressions: https://bugs.llvm.org/show_bug.cgi?id=42708 https://bugs.llvm.org/show_bug.cgi?id=43146 We decided that load combining was unsuitable for IR because it could obscure other optimizations in IR. So we removed the LoadCombiner pass and deferred to the backend. Therefore, preventing SLP from destroying load combine opportunities requires that it recognizes patterns that could be combined later, but not do the optimization itself ( it's not a vector combine anyway, so it's probably out-of-scope for SLP). Here, we add a cost-independent bailout with a conservative pattern match for a multi-instruction sequence that can probably be reduced later. In the x86 tests shown (and discussed in more detail in the bug reports), SDAG combining will produce a single instruction on these tests like: movbe rax, qword ptr [rdi] or: mov rax, qword ptr [rdi] Not some (half) vector monstrosity as we currently do using SLP: vpmovzxbq ymm0, dword ptr [rdi + 1] # ymm0 = mem[0],zero,zero,.. vpsllvq ymm0, ymm0, ymmword ptr [rip + .LCPI0_0] movzx eax, byte ptr [rdi] movzx ecx, byte ptr [rdi + 5] shl rcx, 40 movzx edx, byte ptr [rdi + 6] shl rdx, 48 or rdx, rcx movzx ecx, byte ptr [rdi + 7] shl rcx, 56 or rcx, rdx or rcx, rax vextracti128 xmm1, ymm0, 1 vpor xmm0, xmm0, xmm1 vpshufd xmm1, xmm0, 78 # xmm1 = xmm0[2,3,0,1] vpor xmm0, xmm0, xmm1 vmovq rax, xmm0 or rax, rcx vzeroupper ret Differential Revision: https://reviews.llvm.org/D67841 llvm-svn: 375025
* [lldb] move more things from python to cmakeHaibo Huang2019-10-162-237/+23
| | | | | | | | | | | | | | Summary: Move the copy of six.py, lldb.py and macosx/heap Reviewers: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69016 llvm-svn: 375024
* [lit] Fix a test case that r374652 missedJoel E. Denny2019-10-161-1/+1
| | | | llvm-svn: 375023
* Tag CFI-generated data structures with "#pragma clang section" attributes.Dmitry Mikulin2019-10-165-5/+81
| | | | | | Differential Revision: https://reviews.llvm.org/D68808 llvm-svn: 375022
* [NFC][XCOFF][AIX] Rename ControlSections to CsectGroupJason Liu2019-10-161-4/+4
| | | | | | | | | | | The name of ControlSections is not expressive enough to convey what they really are. CsectGroup can better communicate the concept of grouping csects together since they have similar property. Reviewer: daltenty Differential Revision: https://reviews.llvm.org/D69001 llvm-svn: 375021
* [lit] Fix internal diff's --strip-trailing-cr and use itJoel E. Denny2019-10-1612-13/+83
| | | | | | | | | | | | | | | | | | | | | | | | | Using GNU diff, `--strip-trailing-cr` removes a `\r` appearing before a `\n` at the end of a line. Without this patch, lit's internal diff only removes `\r` if it appears as the last character. That seems useless. This patch fixes that. This patch also adds `--strip-trailing-cr` to some tests that fail on Windows bots when D68664 is applied. Based on what I see in the bot logs, I think the following is happening. In each test there, lit diff is comparing a file with `\r\n` line endings to a file with `\n` line endings. Without D68664, lit diff reads those files in text mode, which in Windows causes `\r\n` to be replaced with `\n`. However, with D68664, lit diff reads the files in binary mode instead and thus reports that every line is different, just as GNU diff does (at least under Ubuntu). Adding `--strip-trailing-cr` to those tests restores the previous behavior while permitting the behavior of lit diff to be more like GNU diff. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D68839 llvm-svn: 375020
* CombinerHelper - silence dead assignment warnings. NFCI.Simon Pilgrim2019-10-161-9/+9
| | | | | | Copy the NewAlignment value to Alignment first and then use that to update the stack frame object alignments. llvm-svn: 375019
* [lit] Clean up internal diff's encoding handlingJoel E. Denny2019-10-167-35/+88
| | | | | | | | | | | | | | | | | | | | | As suggested by rnk at D67643#1673043, instead of reading files multiple times until an appropriate encoding is found, read them once as binary, and then try to decode what was read. For Python >= 3.5, don't fail when attempting to decode the `diff_bytes` output in order to print it. Avoid failures for Python 2.7 used on some Windows bots by transforming diff output with `lit.util.to_string` before writing it to stdout. Finally, add some tests for encoding handling. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D68664 llvm-svn: 375018
* [OPENMP]Use different addresses for zeroed thread_id/bound_id.Alexey Bataev2019-10-165-25/+40
| | | | | | | | When the parallel region is called directly in the sequential region, the zeroed tid/bound id are used. But they must point to the different memory locations as the parameters are marked as noalias. llvm-svn: 375017
* [AMDGPU] Supress unused sdwa insts generationStanislav Mekhanoshin2019-10-163-25/+55
| | | | | | | | | Do not generate non-existing sdwa instructions. It reduces the number of generated instructions by 185. Differential Revision: https://reviews.llvm.org/D69010 llvm-svn: 375016
* [Remarks] Fix warning for ambigous `else` behind EXPECT macroFrancis Visoiu Mistrih2019-10-161-2/+4
| | | | | | http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/31902/steps/ninja%20check%201/logs/stdio llvm-svn: 375015
* [Remarks] Fix unit test by only checking for the pathFrancis Visoiu Mistrih2019-10-161-4/+3
| | | | | | http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/39536/steps/ninja%20check%201/logs/FAIL%3A%20LLVM-Unit%3A%3AYAMLRemarks.ParsingBadMeta llvm-svn: 375014
* [SVE][IR] Small TypeSize improvements left out of initial commitGraham Hunter2019-10-163-8/+8
| | | | | | | The commit for D53137 left out the last round of improvements requested by reviewers. Adding those in now. llvm-svn: 375013
* [DWARF5] Added support for DW_AT_noreturn attribute to be emitted forAdrian Prantl2019-10-163-32/+85
| | | | | | | | | | C++ class member functions. Patch by Sourabh Singh Tomar! Differential Revision: https://reviews.llvm.org/D68697 llvm-svn: 375012
* [Remarks] Use StringRef::contains to avoid differences in error stringFrancis Visoiu Mistrih2019-10-161-9/+21
| | | | | | | | Different OSs have different error strings: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/39534/steps/ninja%20check%201/logs/FAIL%3A%20LLVM-Unit%3A%3AYAMLRemarks.ParsingBadMeta llvm-svn: 375011
* [AArch64,Assembler] Compiler support for ID_MMFR5_EL1Mark Murray2019-10-164-0/+9
| | | | | | | | | | | | Summary: Add read-only system register ID_MMFR5_EL1 and unit tests. Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69039 llvm-svn: 375010
* [Codegen] Adjust saturation test. NFC.David Green2019-10-1620-79/+2418
| | | | | | Add some extra sat tests and adjust some of the existing tests to use signext where it would naturally be. llvm-svn: 375009
* [Remarks] Add support for prepending a path to external filesFrancis Visoiu Mistrih2019-10-167-22/+58
| | | | | | | | | This helps with testing and debugging for paths that are assumed absolute. It also uses a FileError to provide the file path it's trying to open. llvm-svn: 375008
* bpf: fix wrong truncation elimination when there is back-edge/loopJiong Wang2019-10-165-167/+285
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, BPF backend is doing truncation elimination. If one truncation is performed on a value defined by narrow loads, then it could be redundant given BPF loads zero extend the destination register implicitly. When the definition of the truncated value is a merging value (PHI node) that could come from different code paths, then checks need to be done on all possible code paths. Above described optimization was introduced as r306685, however it doesn't work when there is back-edge, for example when loop is used inside BPF code. For example for the following code, a zero-extended value should be stored into b[i], but the "and reg, 0xffff" is wrongly eliminated which then generates corrupted data. void cal1(unsigned short *a, unsigned long *b, unsigned int k) { unsigned short e; e = *a; for (unsigned int i = 0; i < k; i++) { b[i] = e; e = ~e; } } The reason is r306685 was trying to do the PHI node checks inside isel DAG2DAG phase, and the checks are done on MachineInstr. This is actually wrong, because MachineInstr is being built during isel phase and the associated information is not completed yet. A quick search shows none target other than BPF is access MachineInstr info during isel phase. For an PHI node, when you reached it during isel phase, it may have all predecessors linked, but not successors. It seems successors are linked to PHI node only when doing SelectionDAGISel::FinishBasicBlock and this happens later than PreprocessISelDAG hook. Previously, BPF program doesn't allow loop, there is probably the reason why this bug was not exposed. This patch therefore fixes the bug by the following approach: - The existing truncation elimination code and the associated "load_to_vreg_" records are removed. - Instead, implement truncation elimination using MachineSSA pass, this is where all information are built, and keep the pass together with other similar peephole optimizations inside BPFMIPeephole.cpp. Redundant move elimination logic is updated accordingly. - Unit testcase included + no compilation errors for kernel BPF selftest. Patch Review === Patch was sent to and reviewed by BPF community at: https://lore.kernel.org/bpf Reported-by: David Beckett <david.beckett@netronome.com> Reviewed-by: Yonghong Song <yhs@fb.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> llvm-svn: 375007
* [RISCV] Add MachineInstr immediate verificationLuis Marques2019-10-167-4/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the `TargetInstrInfo::verifyInstruction` hook for RISC-V. Currently the hook verifies the machine instruction's immediate operands, to check if the immediates are within the expected bounds. Without the hook invalid immediates are not detected except when doing assembly parsing, so they are silently emitted (including being truncated when emitting object code). The bounds information is specified in tablegen by using the `OperandType` definition, which sets the `MCOperandInfo`'s `OperandType` field. Several RISC-V-specific immediate operand types were created, which extend the `MCInstrDesc`'s `OperandType` `enum`. To have the hook called with `llc` pass it the `-verify-machineinstrs` option. For Clang add the cmake build config `-DLLVM_ENABLE_EXPENSIVE_CHECKS=True`, or temporarily patch `TargetPassConfig::addVerifyPass`. Review concerns: - The patch adds immediate operand type checks that cover at least the base ISA. There are several other operand types for the C extension and one type for the F/D extensions that were left out of this initial patch because they introduced further design concerns that I felt were best evaluated separately. - Invalid register classes (e.g. passing a GPR register where a GPRC is expected) are already caught, so were not included. - This design makes the more abstract `MachineInstr` verification depend on MC layer definitions, which arguably is not the cleanest design, but is in line with how things are done in other parts of the target and LLVM in general. - There is some duplication of logic already present in the `MCOperandPredicate`s. Since the `MachineInstr` and `MCInstr` notions of immediates are fundamentally different, this is currently necessary. Reviewers: asb, lenary Reviewed By: lenary Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67397 llvm-svn: 375006
* [AMDGPU] Fix-up cases where writelane has 2 SGPR operandsDavid Stuttard2019-10-164-8/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Even though writelane doesn't have the same constraints as other valu instructions it still can't violate the >1 SGPR operand constraint Due to later register propagation (e.g. fixing up vgpr operands via readfirstlane) changing writelane to only have a single SGPR is tricky. This implementation puts a new check after SIFixSGPRCopies that prevents multiple SGPRs being used in any writelane instructions. The algorithm used is to check for trivial copy prop of suitable constants into one of the SGPR operands and perform that if possible. If this isn't possible put an explicit copy of Src1 SGPR into M0 and use that instead (this is allowable for writelane as the constraint is for SGPR read-port and not constant-bus access). Reviewers: rampitec, tpr, arsenm, nhaehnle Reviewed By: rampitec, arsenm, nhaehnle Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, mgorny, yaxunl, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D51932 Change-Id: Ic7553fa57440f208d4dbc4794fc24345d7e0e9ea llvm-svn: 375004
* [libTooling] Fix r374962: add more Transformer forwarding decls.Yitzhak Mandelbaum2019-10-164-9/+16
| | | | | | | | | | | | | | | | | | Summary: The move to a new, single namespace in r374962 left out some type definitions from the old namespace and resulted in one naming conflict (`text`). This revision adds aliases for those definitions and removes one of the `text` functions from the new namespace. Reviewers: alexfh Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69036 llvm-svn: 375003
* [llvm-ar] Make paths case insensitive when on windowsOwen Reynolds2019-10-166-8/+108
| | | | | | | | | When on windows gnu-ar treats member names as case insensitive. This commit implements the same behaviour. Differential Revision: https://reviews.llvm.org/D68033 llvm-svn: 375002
* [Driver,ARM] Make -mfloat-abi=soft turn off MVE.Simon Tatham2019-10-162-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since `-mfloat-abi=soft` is taken to mean turning off all uses of the FP registers, it should turn off the MVE vector instructions as well as NEON and scalar FP. But it wasn't doing so. So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft` would cause the underlying LLVM to //not// support MVE (because it knows the real target feature relationships and turned off MVE when the `fpregs` feature was removed), but the clang layer still thought it //was// supported, and would misleadingly define the feature macro `__ARM_FEATURE_MVE`. The ARM driver code already has a long list of feature names to turn off when `-mfloat-abi=soft` is selected. The fix is to add the missing entries `mve` and `mve.fp` to that list. Reviewers: dmgreen Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69025 llvm-svn: 375001
* [Alignment][NFC] Optimize alignToGuillaume Chatelet2019-10-161-1/+11
| | | | | | | | | | | | | | Summary: A small optimization suggested by jakehehrlich@ in D64790. Reviewers: jakehehrlich, courbet Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69023 llvm-svn: 375000
* RedirectingFileSystem::openFileForRead - replace bitwise & with boolean && ↵Simon Pilgrim2019-10-161-1/+1
| | | | | | | | to fix warning Seems to be just a typo - now matches other instances which do something similar llvm-svn: 374995
* RealFile - fix self-initialization warning in constructor.Simon Pilgrim2019-10-161-3/+3
| | | | llvm-svn: 374994
* [InstCombine][AMDGPU] Fix crash with v3i16/v3f16 buffer intrinsicsPiotr Sobczak2019-10-162-0/+52
| | | | | | | | | | | | | | | | | | | | Summary: This is something of a workaround to avoid a crash later on in type legalizer (WidenVectorResult()). Also added some f16 tests, including a non-working v3f16 case with a FIXME. Reviewers: arsenm, tpr, nhaehnle Reviewed By: arsenm Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68865 llvm-svn: 374993
* Revert "[HardwareLoops] Optimisation remarks"Sjoerd Meijer2019-10-164-97/+25
| | | | | | | | while I investigate the PPC build bot failures. This reverts commit ad763751565b9663bc338fa2ca5ade86c6ca22ec. llvm-svn: 374992
* RewriteModernObjC - silence static analyzer getAs<> null dereference ↵Simon Pilgrim2019-10-161-5/+4
| | | | | | | | warnings. NFCI. The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 374991
* [ARM] Add a register class for GPR pairs without SP and use it. NFCIMikhail Maltsev2019-10-163-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently Thumb2InstrInfo.cpp uses a register class which is auto-generated by tablegen. Such approach is fragile because auto-generated classes might change when other register classes are added. For example, before https://reviews.llvm.org/D62667 we were using GPRPair_with_gsub_1_in_rGPRRegClass, but had to change it to GPRPair_with_gsub_1_in_GPRwithAPSRnospRegClass because the former class stopped being generated (this did not change the functionality though). This patch adds a register class consisting of even-odd GPR register pairs from (R0, R1) to (R10, R11), which excludes (R12, SP) and uses it in Thumb2InstrInfo.cpp instead of GPRPair_with_gsub_1_in_GPRwithAPSRnospRegClass. Reviewers: ostannard, simon_tatham, dmgreen, efriedma Reviewed By: simon_tatham Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69026 llvm-svn: 374990
* CGDebugInfo - silence static analyzer dyn_cast<> null dereference warnings. ↵Simon Pilgrim2019-10-161-4/+5
| | | | | | | | NFCI. The static analyzer is warning about potential null dereferences, but in these cases we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 374989
* CGExprConstant - silence static analyzer getAs<> null dereference warning. NFCI.Simon Pilgrim2019-10-161-2/+2
| | | | | | The static analyzer is warning about a potential null dereference, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 374988
* CGBuiltin - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim2019-10-161-5/+4
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 374987
* SimpleLoopUnswitch - fix uninitialized variable and null dereference ↵Simon Pilgrim2019-10-161-2/+3
| | | | | | warnings. NFCI. llvm-svn: 374986
* Revert 374967 "[Concepts] ConceptSpecializationExprs mangling"Nico Weber2019-10-163-31/+4
| | | | | | | | | | | | | | | This reverts commit 5e34ad109ced8dbdea9500ee28180315b2aeba3d. The mangling test fails on Windows: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15944 It also fails on ppc64le: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/21092 Also revert follow-up 374971 "Fix failing mangle-concept.cpp test." (it did not help on Win/ppc64le). llvm-svn: 374985
* [AMDGPU] Extend the SI Load/Store optimizerPiotr Sobczak2019-10-163-13/+1818
| | | | | | | | | | | | | | | | | | | | | Summary: Extend the SI Load/Store optimizer to merge MIMG load instructions. Handle different flavours of image_load and image_sample instructions. When the instructions of the same subclass differ only in dmask, merge them and update dmask accordingly. Reviewers: nhaehnle Reviewed By: nhaehnle Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64911 llvm-svn: 374984
* gn build: Merge r374982GN Sync Bot2019-10-161-0/+1
| | | | llvm-svn: 374983
* [clangd] Add RemoveUsingNamespace tweak.Utkarsh Saxena2019-10-165-17/+459
| | | | | | | | | | | | | | | | | | Summary: Removes the 'using namespace' under the cursor and qualifies all accesses in the current file. E.g.: using namespace std; vector<int> foo(std::map<int, int>); Would become: std::vector<int> foo(std::map<int, int>); Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68562 llvm-svn: 374982
* [ARM][ParallelDSP] Change smlad insertion orderSam Parker2019-10-1613-91/+316
| | | | | | | | | | Instead of inserting everything after the 'root' of the reduction, insert all instructions as close to their operands as possible. This can help reduce register pressure. Differential Revision: https://reviews.llvm.org/D67392 llvm-svn: 374981
* [HardwareLoops] Optimisation remarksSjoerd Meijer2019-10-164-25/+97
| | | | | | | | | | | | This adds the initial plumbing to support optimisation remarks in the IR hardware-loop pass. I have left a todo in a comment where we can improve the reporting, and will iterate on that now that we have this initial support in. Differential Revision: https://reviews.llvm.org/D68579 llvm-svn: 374980
* [NFC] Replace a linked list in LiveDebugVariables pass with a DenseMapOrlando Cazalet-Hyams2019-10-161-82/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In LiveDebugVariables.cpp: Prior to this patch, UserValues were grouped into linked list chains. Each chain was the union of two sets: { A: Matching Source variable } or { B: Matching virtual register }. A ptr to the heads (or 'leaders') of each of these chains were kept in a map with the { Source variable } used as the key (set A predicate) and another with { Virtual register } as key (set B predicate). There was a search through the chains in the function getUserValue looking for UserValues with matching { Source variable, Complex expression, Inlined-at location }. Essentially searching for a subset of A through two interleaved linked lists of set A and B. Importantly, by design, the subset will only contain one or zero elements here. That is to say a UserValue can be uniquely identified by the tuple { Source variable, Complex expression, Inlined-at location } if it exists. This patch removes the linked list and instead uses a DenseMap to map the tuple { Source variable, Complex expression, Inlined-at location } to UserValue ptrs so that the getUserValue search predicate is this map key. The virtual register map now maps a vreg to a SmallVector<UserVal *> so that set B is still available for quick searches. Reviewers: aprantl, probinson, vsk, dblaikie Reviewed By: aprantl Subscribers: russell.gallop, gbedwell, bjope, hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D68816 llvm-svn: 374979
* [CMake] Disable building all Darwin libraries (except builtins) for macOS ↵Dan Liew2019-10-161-1/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i386 when the SDK is >= 10.15. Summary: In the macOS 10.15 SDK the ability to link i386 binaries was removed and in the corresponding OS it is not possible to run macOS i386 binaries. The consequence of these changes meant that targets like `check-asan` would fail because: * Unit tests could not be linked for i386 * Lit tests for i386 would fail due to not being able to execute compiled binaries. The simplest fix to this is to simply disable building for i386 for macOS when using the 10.15 SDK (or newer). This disables building the i386 slice for most compiler-rt libraries and consequently disables the unit and lit tests for macOS i386. Note that because the `DARWIN_osx_ARCHS` CMake variable is a cache variable this patch will have no affect on existing builds unless the existing cache variable is deleted. The simplest way to deal with this is delete existing builds and just do a fresh configure. Note this should not affect the builtins which are managed with the `DARWIN_osx_BUILTIN_ARCHS` CMake cache variable. For those who wish to force using a particular set of architectures when using newer SDKs passing `-DDARWIN_osx_ARCHS=i386;x86_64;x86_64h` to CMake should provide a usable (but completely unsupported) workaround. rdar://problem/55668535 rdar://problem/47939978 Reviewers: kubamracek, yln, azhar, kcc, dvyukov, vitalybuka, cryptoad, eugenis, thakis, phosek Subscribers: mgorny, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68292 llvm-svn: 374977
* [LegalizeTypes] Don't use PromoteTargetBoolean in WidenVecOp_SETCC.Craig Topper2019-10-161-1/+4
| | | | | | | | | | | | | Similar to r374970, but I don't have a test for this. PromoteTargetBoolean is intended to be use for legalizing an operand that needs to be promoted. It picks its type based on the return from getSetccResultType and is intended to be used when we have freedom to pick the new type. But the return type we need for WidenVecOp_SETCC is completely determined by the type of the input node. llvm-svn: 374972
* Fix failing mangle-concept.cpp test.Saar Raz2019-10-161-2/+2
| | | | llvm-svn: 374971
* [LegalizeTypes] Don't call PromoteTargetBoolean from SplitVecOp_VSETCC.Craig Topper2019-10-162-1/+112
| | | | | | | | | | | | | | | PromoteTargetBoolean calls getSetccResultType to get the return type. But we were passing it the setcc result type rather than the setcc input type. This causes an issue on X86 with avx512vl where the setcc result type for vXf16 vectors is vXi16 while the result type for vXi16 vectors is vXi1. There's really no guarantee that getSetccResultType is the type we need here. So now we just grab the extend type from getExtendForContent and extend to the original result VT of the node we're splitting. llvm-svn: 374970
OpenPOWER on IntegriCloud