summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [X86] Refactor X86IndirectThunks.cpp to Accommodate Mitigations other than ↵Scott Constable2020-06-241-125/+157
| | | | | | | | Retpoline Introduce a ThunkInserter CRTP base class from which new thunk types can inherit, e.g., thunks to mitigate https://software.intel.com/security-software-guidance/software-guidance/load-value-injection. Differential Revision: https://reviews.llvm.org/D76811
* [X86][NFC] Generalize the naming of "Retpoline Thunks" and related code to ↵Scott Constable2020-06-2416-115/+137
| | | | | | | | | | | | "Indirect Thunks" There are applications for indirect call/branch thunks other than retpoline for Spectre v2, e.g., https://software.intel.com/security-software-guidance/software-guidance/load-value-injection Therefore it makes sense to refactor X86RetpolineThunks as a more general capability. Differential Revision: https://reviews.llvm.org/D76810
* Move RDF from Hexagon to CodegenScott Constable2020-06-2414-27/+29
| | | | | | | | RDF is designed to be target agnostic. Therefore it would be useful to have it available for other targets, such as X86. Based on a previous patch by Krzysztof Parzyszek Differential Revision: https://reviews.llvm.org/D75932
* [Driver] Support -fsanitize=shadow-call-stack and cfi-icall on aarch64_beFangrui Song2020-06-242-8/+6
| | | | | | | D80647 did not fix https://bugs.llvm.org/show_bug.cgi?id=46076 This is the fix. (cherry picked from commit b9c6871a9570975827dc0bbeb39131c99c8daf8e)
* [Driver] Support -fsanitize=shadow-call-stack on aarch64_beFangrui Song2020-06-242-2/+5
| | | | | | | | | | Fixes https://bugs.llvm.org/show_bug.cgi?id=46076 Reviewed By: nickdesaulniers, pcc Differential Revision: https://reviews.llvm.org/D80647 (cherry picked from commit a2a3e9f0a6e91103a0d1fa73086dbdf109c48f69)
* [InstCombine] prevent infinite loop with sub/abs of constant expressionTom Stellard2020-06-232-1/+19
| | | | | | | PR45539: https://bugs.llvm.org/show_bug.cgi?id=45539 (cherry picked from commit 01bcc3e9371470e1974f066ced353df15e10056d)
* [ManagedStatic] Fix build errors with clang-tblgen in Debug mode using MSVC ↵Denys Petrov2020-06-231-2/+2
| | | | | | | | | | | | | | | | | 2019 v16.6 After updating MSVS19 from v16.4 to v16.6 I faced with a build errors compiling in Debug mode. It complains on clang-tblgen.exe and llvm-tblgen.exe cmd line args. VS compiler had a bug. It dynamically creates an object with constexpr ctor in Debug mode. This bug was fixed in VS2019 v16.5. A workaround was implemented for that and everything works until v16.5 comes. The workaround became irrelevant since v16.5 and caused build errors. So I disabled the workaround for VS2019 v16.5 and higher. This relates to http://llvm.org/PR41367. Differential Revision: https://reviews.llvm.org/D80433 (cherry picked from commit 46e5c5fe778b92b2a7e2c2ad3610e1da6794bd5e)
* [compiler-rt] Reduce the number of threads in gcov test to avoid failureCalixte Denizet2020-06-231-15/+5
| | | | | | | | | | | | | | | | | | | | Summary: Patch in D78477 introduced a new test for gcov and this test is failing on arm: - http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-full-sh/builds/4752/steps/ninja%20check%202/logs/stdio - http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/10501/steps/ninja%20check%202/logs/stdio So try to fix it in reducing the number of threads. Reviewers: marco-c Reviewed By: marco-c Subscribers: dberris, kristof.beyls, #sanitizers, serge-sans-paille, sylvestre.ledru Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D79621 (cherry picked from commit 0da37bedc2667da371eda30595a06210595881d0)
* [BasicAA] Make BasicAA a cfg pass.Alina Sbirlea2020-06-235-17/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: Part of the changes in D44564 made BasicAA not CFG only due to it using PhiAnalysisValues which may have values invalidated. Subsequent patches (rL340613) appear to have addressed this limitation. BasicAA should not be invalidated by non-CFG-altering passes. A concrete example is MemCpyOpt which preserves CFG, but we are testing it invalidates BasicAA. llvm-dev RFC: https://groups.google.com/forum/#!topic/llvm-dev/eSPXuWnNfzM Reviewers: john.brawn, sebpop, hfinkel, brzycki Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74353 (cherry picked from commit 0cecafd647ccd9d0acc5968d4d6e80c1cbdee275)
* [PowerPC] Do not assume operand of ADDI is an immediateNemanja Ivanovic2020-06-232-0/+56
| | | | | | | | | | After pseudo-expansion, we may end up with ADDI (add immediate) instructions where the operand is not an immediate but a relocation. For such instructions, attempts to get the immediate result in assertion failures for obvious reasons. Fixes: https://bugs.llvm.org/show_bug.cgi?id=45432 (cherry picked from commit a56d057dfe3127c111c3470606c04e96d35b1fa3)
* [BPF] fix incorrect type in BPFISelDAGToDAG readonly load optimizationYonghong Song2020-06-232-1/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In BPF Instruction Selection DAGToDAG transformation phase, BPF backend had an optimization to turn load from readonly data section to direct load of the values. This phase is implemented before libbpf has readonly section support and before alu32 is supported. This phase however may generate incorrect type when alu32 is enabled. The following is an example, -bash-4.4$ cat ~/tmp2/t.c struct t { unsigned char a; unsigned char b; unsigned char c; }; extern void foo(void *); int test() { struct t v = { .b = 2, }; foo(&v); return 0; } The compiler will turn local variable "v" into a readonly section. During instruction selection phase, the compiler generates two loads from readonly section, one 2 byte load or 1 byte load, e.g., for 2 loads, t8: i32,ch = load<(dereferenceable load 2 from `i8* getelementptr inbounds (%struct.t, %struct.t* @__const.test.v, i64 0, i32 0)`, align 1), anyext from i16> t3, GlobalAddress:i64<%struct.t* @__const.test.v> 0, undef:i64 t9: ch = store<(store 2 into %ir.v1.sub1), trunc to i16> t3, t8, FrameIndex:i64<0>, undef:i64 BPF backend changed t8 to i64 = Constant<2> and eventually the generated machine IR: t10: i64 = MOV_ri TargetConstant:i64<2> t40: i32 = SLL_ri_32 t10, TargetConstant:i32<8> t41: i32 = OR_ri_32 t40, TargetConstant:i64<0> t9: ch = STH32<Mem:(store 2 into %ir.v1.sub1)> t41, TargetFrameIndex:i64<0>, TargetConstant:i64<0>, t3 Note that t10 in the above is not correct. The type should be i32 and instruction should be MOV_ri_32. The reason for incorrect insn selection is BPF insn selection generated an i64 constant instead of an i32 constant as specified in the original load instruction. Such incorrect insn sequence eventually caused the following fatal error when a COPY insn tries to copy a 64bit register to a 32bit subregister. Impossible reg-to-reg copy UNREACHABLE executed at ../lib/Target/BPF/BPFInstrInfo.cpp:42! This patch fixed the issue by using the load result type instead of always i64 when doing readonly load optimization. Differential Revision: https://reviews.llvm.org/D81630 (cherry picked from commit 4db1878158a3f481ff673fef2396c12b7a53d280)
* Make LLVM_APPEND_VC_REV=OFF affect clang, lld, and lldb as well.Nico Weber2020-06-235-7/+9
| | | | | | | | | | | | | | | | | | When LLVM_APPEND_VC_REV=OFF is set, the current git hash is no longer embedded into binaries (mostly for --version output). Without it, most binaries need to relink after every single commit, even if they didn't change otherwise (due to, say, a documentation-only commit). LLVM_APPEND_VC_REV is ON by default, so this doesn't change the default behavior of anything. With this, all clients of GenerateVersionFromVCS.cmake honor LLVM_APPEND_VC_REV. Differential Revision: https://reviews.llvm.org/D72855 (cherry picked from commit fb5fafb23cc2d8613f8be2487afe94d8594a88ce)
* [clangd] Fix DocumentOutline for conceptsKadir Cetinkaya2020-06-232-2/+14
| | | | | | | | | | | | | | Summary: Fixes https://github.com/clangd/clangd/issues/256 Reviewers: kbobyrev Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73056 (cherry picked from commit fb3d9153c01b9a560680465190d6ecd804e4c486)
* [BPF] fix a bug for BTF pointee type pruningYonghong Song2020-06-233-0/+280
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In BTF, pointee type pruning is used to reduce cluttering too many unused types into prog BTF. For example, struct task_struct { ... struct mm_struct *mm; ... } If bpf program does not access members of "struct mm_struct", there is no need to bring types for "struct mm_struct" to BTF. This patch fixed a bug where an incorrect pruning happened. The test case like below: struct t; typedef struct t _t; struct s1 { _t *c; }; int test1(struct s1 *arg) { ... } struct t { int a; int b; }; struct s2 { _t c; } int test2(struct s2 *arg) { ... } After processing test1(), among others, BPF backend generates BTF types for "struct s1", "_t" and a placeholder for "struct t". Note that "struct t" is not really generated. If later a direct access to "struct t" member happened, "struct t" BTF type will be generated properly. During processing test2(), when processing member type "_t c", BPF backend sees type "_t" already generated, so returned. This caused the problem that "struct t" BTF type is never generated and eventually causing incorrect type definition for "struct s2". To fix the issue, during DebugInfo type traversal, even if a typedef/const/volatile/restrict derived type has been recorded in BTF, if it is not a type pruning candidate, type traversal of its base type continues. Differential Revision: https://reviews.llvm.org/D82041 (cherry picked from commit 89648eb16d01725457f958e634d16c534b64c42c)
* [PowerPC] Unaligned FP default should apply to scalars onlyNemanja Ivanovic2020-06-232-1/+134
| | | | | | | | | | As reported in PR45186, we could be in a situation where we don't want to handle unaligned memory accesses for FP scalars but still have VSX (which allows unaligned access for vectors). Change the default to only apply to scalars. Fixes: https://bugs.llvm.org/show_bug.cgi?id=45186 (cherry picked from commit 099a875f28d0131a6ae85af91b9eb8627917fbbe)
* Fixed false ThinLTO cache misses problem (PR 45819).romanova-ekaterina2020-06-221-4/+24
| | | | | | | | | | | | We relied on the fact that the iterators walks through the elements of a DenseSet in a deterministic order (which is not true). This caused ThinLTO cache misses. This patch addresses this problem. See PR 45819 for additional information https://bugs.llvm.org/show_bug.cgi?id=45819 Differential Revision: https://reviews.llvm.org/D79772 (cherry picked from commit 252892fea7088abbeff9476e0ecbacc091d135a0)
* [PowerPC] Treat 'Z' inline asm constraint as a true memory constraintNemanja Ivanovic2020-06-222-1/+15
| | | | | | | | | | | | We currently emit incorrect codegen for this constraint because we set it as a constraint that allows registers. This will cause the value to be copied to the stack and that address to be passed as the address. This is not what we want. Fixes: https://bugs.llvm.org/show_bug.cgi?id=42762 Differential revision: https://reviews.llvm.org/D77542 (cherry picked from commit aede24ecaa08db806fb173faf2de9cff95df8cee)
* [PowerPC] Prevent legalization loop from promoting SELECT_CC from v4i32 to v4i32Nemanja Ivanovic2020-06-222-0/+59
| | | | | | | | | | | | | As reported in https://bugs.llvm.org/show_bug.cgi?id=45709 we can hit an infinite loop in legalization since we set the legalization action for ISD::SELECT_CC for all fixed length vector types to Promote. Without some different legalization action for the type being promoted to, the legalizer simply loops. Since we don't have patterns to match the node, the right legalization action should be Expand. Differential revision: https://reviews.llvm.org/D79854 (cherry picked from commit 793cc518b9428a0b7a40c59d4ecd5939a7bc84f7)
* [PowerPC] Add missing handling for half precisionTom Stellard2020-06-226-177/+104
| | | | | | | | | | | | The fix for PR39865 took care of some of the handling for half precision but it missed a number of issues that still exist. This patch fixes the remaining issues that cause crashes in the PPC back end. Fixes: https://bugs.llvm.org/show_bug.cgi?id=45776 Differential revision: https://reviews.llvm.org/D79283 (cherry picked from commit 1a493b0fa556a07c728862c3c3f70bfd8683bef0)
* [PowerPC] Add support for vmsumudmAhsan Saghir2020-06-225-0/+14
| | | | | | | | | This patch adds support for Vector Multiply-Sum Unsigned Doubleword Modulo instruction; vmsumudm. Differential Revision: https://reviews.llvm.org/D80294 (cherry picked from commit a28e9f1208608f8d18750bb88ca74722fb0bcce4)
* Make Polly tests dependencies explicitserge-sans-paille2020-06-171-0/+2
| | | | | | | | | Due to libPolly now using the component infrastructure, it no longer carries all dependencies as it used to do. Differential Revision: https://reviews.llvm.org/D79295 (cherry picked from commit 8ceee08de135c4c96980bd750bb5e95348126980)
* Fix spurious warning in ExtensionDependencies.inc [nfc]serge-sans-paille2020-06-171-3/+3
| | | | (cherry picked from commit 37309fb02f60557f18971dc575904c0fc56c91ab)
* Use components instead of libraries in Polly linkage stepserge-sans-paille2020-06-172-39/+38
| | | | | | | | | As a side effect, this tests (and fix a bug) in the compiler extension handling of components. Differential Revision: https://reviews.llvm.org/D78358 (cherry picked from commit e849e7a700907441ee82ace9d0a9555ae7eb9811)
* Do not declare compiler extension member as constserge-sans-paille2020-06-171-1/+1
| | | | | | It keeps them default constructible. (cherry picked from commit e307eeba0137700e75893089cf0de03383d851ca)
* Update compiler extension integration into the build systemserge-sans-paille2020-06-1712-22/+113
| | | | | | | | | | | | The approach here is to create a new (empty) component, `Extensions', where all statically compiled extensions dynamically register their dependencies. That way we're more natively compatible with LLVMBuild and llvm-config. Fixes: https://bugs.llvm.org/show_bug.cgi?id=44870 Differential Revision: https://reviews.llvm.org/D78192 (cherry picked from commit 8f766e382b77eef3102798b49e087d1e4804b984)
* [nfc] Cleanup extension header generationserge-sans-paille2020-06-171-6/+7
| | | | (cherry picked from commit f44a508df629ecc97e0b1345726b12f25927409e)
* Fix compiler extension in standalone modeserge-sans-paille2020-06-174-35/+35
| | | | | | | | | | | | Use a dedicated cmake file to store the extension configured within LLVM. That way, a standalone build of clang can load this cmake file and get all the configured standalone extensions. This patch is related to https://reviews.llvm.org/D74602 Differential Revision: https://reviews.llvm.org/D74757 (cherry picked from commit 3a0f6e699bb6d96dc62dce6faef20ac26cf103fd)
* Fix standalone build interaction with compiler extensionserge-sans-paille2020-06-172-21/+40
| | | | | | | | | | | | As suggested in https://github.com/llvm/llvm-project/issues/120, don't try to generate the extension file from clang, only do the linking step. Fixes the regression introduced in D74464 when running cmake inside the clang directory. Differential Revision: https://reviews.llvm.org/D74602 (cherry picked from commit 87dac7da68ea1e0adac78c59ef1891dcf9632b67)
* Fix integration of pass plugins with llvm dylibserge-sans-paille2020-06-172-2/+2
| | | | | | | | Call llvm_process_pass_plugin from clang when in standalone mode. Differential Revision: https://reviews.llvm.org/D74464 (cherry picked from commit d21664cce1db8debe2528f36b1fbd2b8af9c9401)
* Fix alignment of thunks for ARM/ARM64Martin Storsjö2020-06-173-16/+30
| | | | | | | | | | | | | | The alignment of ARM64 range extension thunks was fixed in 7c816492197a, but ARM range extension thunks, and import and delay import thunks also need aligning (like all code on ARM platforms). I'm adding a test for alignment of ARM64 import thunks - not specifically adding tests for misalignment of all of them though. Differential Revision: https://reviews.llvm.org/D77796 (cherry picked from commit 12c9e2f1110a4fc73562214cf5dd0194b31e87cf)
* [AARch64] Add Marvell ThunderX3T110 supportWei Zhao2020-06-1722-16/+2101
| | | | | | | | | | | This is the first checkin to support Marvell ThunderX3T110. Initial definition of the micro-ops of the instructions in ThunderX3T110 is included. Differential Revision: https://reviews.llvm.org/D78129 (cherry picked from commit 382d3a85e2a9269569e7fb8caa487d7ef57900c6)
* [X86] make sure POP has implicit def/use of stack pointer when materializing ↵Yuanfang Chen2020-06-172-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 8-bit immediates for minsize Summary: Otherwise PostRA list scheduler may reorder instruction, such as schedule this ''' pushq $0x8 pop %rbx lea 0x2a0(%rsp),%r15 ''' to ''' pushq $0x8 lea 0x2a0(%rsp),%r15 pop %rbx ''' by mistake. The patch is to prevent this to happen by making sure POP has implicit use of SP. Reviewers: craig.topper Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77031 (cherry picked from commit ece79f47083babcabde3700c67b90ef19967a5b3)
* [ELF] Don't cause assertion failure if --dynamic-list or --version-script ↵Fangrui Song2020-06-163-1/+14
| | | | | | | | | takes an empty file Fixes PR46184 Report line 1 of the last memory buffer. (cherry picked from commit ac6abc99e2794e4674a8498f817fda19b176bbfe)
* [IndVarSimplify][LoopUtils] Avoid TOCTOU/ordering issues (PR45835)Tom Stellard2020-06-162-34/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, `rewriteLoopExitValues()`'s logic is roughly as following: > Loop over each incoming value in each PHI node. > Query whether the SCEV for that incoming value is high-cost. > Expand the SCEV. > Perform sanity check (`isValidRewrite()`, D51582) > Record the info > Afterwards, see if we can drop the loop given replacements. > Maybe perform replacements. The problem is that we interleave SCEV cost checking and expansion. This is A Problem, because `isHighCostExpansion()` takes special care to not bill for the expansions that were already expanded, and we can reuse. While it makes sense in general - if we know that we will expand some SCEV, all the other SCEV's costs should account for that, which might cause some of them to become non-high-cost too, and cause chain reaction. But that isn't what we are doing here. We expand *all* SCEV's, unconditionally. So every next SCEV's cost will be affected by the already-performed expansions for previous SCEV's. Even if we are not planning on keeping some of the expansions we performed. Worse yet, this current "bonus" depends on the exact PHI node incoming value processing order. This is completely wrong. As an example of an issue, see @dmajor's `pr45835.ll` - if we happen to have a PHI node with two(!) identical high-cost incoming values for the same basic blocks, we would decide first time around that it is high-cost, expand it, and immediately decide that it is not high-cost because we have an expansion that we could reuse (because we expanded it right before, temporarily), and replace the second incoming value but not the first one; thus resulting in a broken PHI. What we instead should do for now, is not perform any expansions until after we've queried all the costs. Later, in particular after `isValidRewrite()` is an assertion (D51582) we could improve upon that, but in a more coherent fashion. See [[ https://bugs.llvm.org/show_bug.cgi?id=45835 | PR45835 ]] Reviewers: dmajor, reames, mkazantsev, fhahn, efriedma Reviewed By: dmajor, mkazantsev Subscribers: smeenai, nikic, hiraditya, javed.absar, llvm-commits, dmajor Tags: #llvm Differential Revision: https://reviews.llvm.org/D79787 (cherry picked from commit b2df96123198deadad74634c978e84912314da26)
* [AArch64] Fix BTI instruction emission.Daniel Kiss2020-06-162-5/+15
| | | | | | | | | | | | | | | | | | | | | | Summary: SCTLR_EL1.BT[01] controls the PACI[AB]SP compatibility with PBYTE 11 (see [1]) This bit will be set to zero so PACI[AB]SP are equal to BTI C instruction only. [1] https://developer.arm.com/docs/ddi0595/b/aarch64-system-registers/sctlr_el1 Reviewers: chill, tamas.petz, pbarrio, ostannard Reviewed By: tamas.petz, ostannard Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81746 (cherry picked from commit b8ae3fdfa579dbf366b1bb1cbfdbf8c51db7fa55)
* [AArch64] Fix BTI landing pad generation.Daniel Kiss2020-06-162-0/+35
| | | | | | | | | | In some cases BTI landing pad is inserted even compatible instruction was there already. Meta instruction does not count in this case therefore skip them in the check for first instructions in the function. Differential revision: https://reviews.llvm.org/D74492 (cherry picked from commit d5a186a60014dc1a8c979c978cb32aba7ecb9102)
* [lld][ELF] Mark empty NOLOAD output sections SHT_NOBITS instead of SHT_PROGBITSMatt Schulte2020-06-162-3/+6
| | | | | | | | | | | This fixes PR# 45336. Output sections described in a linker script as NOLOAD with no input sections would be marked as SHT_PROGBITS. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D76981 (cherry picked from commit fdc41aa22c60958e6b6df461174b814a4aae3384)
* [ELF][test] Make tests less address sensitive and delete redundant testsFangrui Song2020-06-167-164/+22
| | | | (cherry picked from commit 09ac859c136b406231ef7547f3800111dd00bc7e)
* [X86] Fold undef elts to 0 in getTargetVShiftByConstNode.Craig Topper2020-06-162-17/+20
| | | | | | | | Similar to D81212. Differential Revision: https://reviews.llvm.org/D81292 (cherry picked from commit 3408dcbdf054ac3cc32a97a6a82a3cf5844be609)
* [X86] Teach combineVectorShiftImm to constant fold undef elements to 0 not ↵Craig Topper2020-06-162-4/+12
| | | | | | | | | | | | | | undef. Shifts are supposed to always shift in zeros or sign bits regardless of their inputs. It's possible the input value may have been replaced with undef by SimplifyDemandedBits, but the shift in zeros are still demanded. This issue was reported to me by ispc from 10.0. Unfortunately their failing test does not fail on trunk. Seems to be because the shl is optimized out earlier now and doesn't become VSHLI. ispc bug https://github.com/ispc/ispc/issues/1771 Differential Revision: https://reviews.llvm.org/D81212 (cherry picked from commit 7c9a89fed8f5d53d61fe3a61a2581a7c28b1b6d2)
* lit googletest.py: Don't raise StopIteration in generatorHans Wennborg2020-06-161-1/+1
| | | | | | | | | | The intention here seems to be to end the generator function, but with modern Python, raising StopIteration causes a runtime error (https://www.python.org/dev/peps/pep-0479/). Differential revision: https://reviews.llvm.org/D79169 (cherry picked from commit 88aad9b9f05702585eb823d0188996f4cf62070a)
* [clangd] Use printf instead of `echo -e` to be compliant with dashKadir Cetinkaya2020-06-161-2/+2
| | | | (cherry picked from commit ca1c21d4b659bfa5edb38c4a54b3050e43c4b51a)
* [clangd] Disable dependency-output lit test on windowsKadir Cetinkaya2020-06-161-0/+1
| | | | (cherry picked from commit a940a246f5e14a8fd44586f609b8a675eb949469)
* ValueMapper does not preserve inline assembly dialect when remapping the typeCraig Topper2020-06-111-1/+2
| | | | | | | | | | Bug report: https://bugs.llvm.org/show_bug.cgi?id=45291 Patch by Tomasz Miąsko Differential Revision: https://reviews.llvm.org/D80066 (cherry picked from commit 5f65faef2c61bfb5e041f74db61665f43a05e9db)
* [X86] Add x, t and g modifiers for inline asmCraig Topper2020-06-113-3/+100
| | | | | | | | | | | | This patch adds the x, t and g modifiers for inline asm from GCC. These will print a vector register as xmm*, ymm* or zmm* respectively. I also fixed register names with modifiers with inteldialect so they are no longer printed with a leading %. Patch by Amanieu d'Antras Differential Revision: https://reviews.llvm.org/D78977 (cherry picked from commit c5f7c039efe7ff09a44cfd252f6cb001ceed6269)
* [clangd] Preserve -nostdinc and --sysroot when calling query driverKadir Cetinkaya2020-06-102-13/+47
| | | | | | | | | | | | | | Solves this issue: https://github.com/clangd/clangd/issues/157 This is my first contribution to an llvm project, so I hope I'm doing it right! Patch by @topisani (Tobias Pisani)! Reviewers: kadircet, klimek Differential Revision: https://reviews.llvm.org/D73811 (cherry picked from commit 6e8d6bc9ec8739ec22b73a23f740f171f452e234)
* [clangd] Fix a crash for accessing a null template decl returned by ↵Haojian Wu2020-06-102-9/+37
| | | | | | | | | | | | | | | | | | | findExplicitReferences. Summary: Fixes https://github.com/clangd/clangd/issues/347. Reviewers: kadircet Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D78626 (cherry picked from commit 7d1ee639cb9efea364bec90afe4d1161ec624a7f) Includes some test-only changes from f651c402a221a20f3bc6ea43f70b29326a357010 to support the cherry-picked tests. Test tweaked slightly as it exhibits a separate bug that was fixed on master.
* [Syntax] Merge overlapping top-level macros in TokenBufferSam McCall2020-06-102-9/+50
| | | | | | | | | | | | | | | | | | | Summary: Our previous definition of "top-level" was too informal, and didn't allow for overlapping macros that each directly produce expanded tokens. See D77507 for previous discussion. Fixes http://bugs.llvm.org/show_bug.cgi?id=45428 Reviewers: kadircet, vabridgers Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77615 (cherry picked from commit d66afd6dde542dc373f87e07fe764c071fe20d76)
* [Syntax] Simplify TokenCollector::Builder, use captured expansion bounds. NFCSam McCall2020-06-101-158/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The motivation here is fixing https://bugs.llvm.org/show_bug.cgi?id=45428, see D77507. The fundamental problem is that a "top-level" expansion wasn't precisely defined. Repairing this concept means that TokenBuffer's "top-level expansion" may not correspond to a single macro expansion. Example: ``` M(2); // expands to 1+2 ``` The expansions overlap, but neither expansion alone yields all the tokens. We need a TokenBuffer::Mapping that corresponds to their union. This is fairly easy to fix in CollectPPExpansions, but the current design of TokenCollector::Builder needs a fix too as it relies on the macro's expansion range rather than the captured expansion bounds. This fix is hard to make due to the way code is reused within Builder. And honestly, I found that code pretty hard to reason about too. The new approach doesn't use the expansion range, but only the expansion location: it assumes an expansion is the contiguous set of expanded tokens with the same expansion location, which seems like a reasonable formalization of the "top-level" notion. And hopefully the control flow is easier to follow too, it's considerably shorter even with more documentation. Reviewers: kadircet Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77614 (cherry picked from commit ec0b9908952a9f4a19c3eb92ba0fc01cffcb8614)
* [clangd] Increase stack size of the new threads on macOSSam McCall2020-06-102-10/+32
| | | | | | | | | | | | | | | | | | | | Summary: By default it's 512K, which is way to small for clang parser to run on. There is no way to do it via platform-independent API, so it's implemented via pthreads directly in clangd/Threading.cpp. Fixes https://github.com/clangd/clangd/issues/273 Patch by Dmitry Kozhevnikov! Reviewers: ilya-biryukov, sammccall, arphaman Reviewed By: ilya-biryukov, sammccall, arphaman Subscribers: dexonsmith, umanwizard, jfb, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D50993 (cherry picked from commit 69a39dc1f0d08ea43bac03a87bb8bff3937ce2e7)
OpenPOWER on IntegriCloud