Commit Graph

359912 Commits

Author SHA1 Message Date
Florian Hahn
ec00aa99dd [DomTreeUpdater] Use const auto * when iterating over pointers (NFC).
This silences the warning below:

llvm-project/llvm/lib/Analysis/DomTreeUpdater.cpp:510:20: warning: loop variable 'BB' is always a copy because the range of type 'const SmallPtrSet<llvm::BasicBlock *, 8>' does not return a reference [-Wrange-loop-analysis]
  for (const auto &BB : DeletedBBs) {
                   ^
llvm-project/llvm/lib/Analysis/DomTreeUpdater.cpp:510:8: note: use non-reference type 'llvm::BasicBlock *'
  for (const auto &BB : DeletedBBs) {
       ^~~~~~~~~~~~~~~~
1 warning generated.
2020-07-10 16:39:15 +01:00
Florian Hahn
eb5c7f6b8f [ARM] Add test with tcreturn and debug value.
In the attached test case, a non-terminator instruction (DBG_VALUE) is
inserted after a terminator, producing an invalid MBB.
2020-07-10 16:32:21 +01:00
Sanjay Patel
d84b4e163d [AArch64][x86] add tests for rotated store merge; NFC 2020-07-10 11:28:51 -04:00
Sanjay Patel
02fec9d2a5 [DAGCombiner] move/rename variables for readability; NFC 2020-07-10 11:28:51 -04:00
Nicolas Vasilache
a490d387e6 [mlir][Vector] Add ExtractOp folding when fed by a TransposeOp
TransposeOp are often followed by ExtractOp.
In certain cases however, it is unnecessary (and even detrimental) to lower a TransposeOp to either a flat transpose (llvm.matrix intrinsics) or to unrolled scalar insert / extract chains.

Providing foldings of ExtractOp mitigates some of the unnecessary complexity.

Differential revision: https://reviews.llvm.org/D83487
2020-07-10 11:09:27 -04:00
Joel E. Denny
9fd4b5faac [FileCheck] Implement -dump-input-filter
This makes the input dump filtering implemented by D82203 more
configurable.  D82203 enables filtering out everything but the initial
input lines of error diagnostics (plus some context).  This patch
enables including any line with any kind of annotation.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D83097
2020-07-10 11:02:11 -04:00
Joel E. Denny
77b6ddf1bd [FileCheck] In input dump, elide only if ellipsis is shorter
For example, given `-dump-input-context=3 -vv`, the following now
shows more leading context for the error than requested because a
leading ellipsis would occupy the same number of lines as it would
elide:

```
<<<<<<
         1: foo6
         2: foo5
         3: foo4
         4: foo3
         5: foo2
         6: foo1
         7: hello world
check:1     ^~~~~
check:2           X~~~~ error: no match found
         8: foo1
check:2     ~~~~
         9: foo2
check:2     ~~~~
        10: foo3
check:2     ~~~~
         .
         .
         .
>>>>>>
```

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D83526
2020-07-10 11:02:11 -04:00
Joel E. Denny
bce8fced41 [FileCheck] Implement -dump-input-context
This patch is motivated by discussions at each of:

* <https://reviews.llvm.org/D81422>
* <http://lists.llvm.org/pipermail/llvm-dev/2020-June/142369.html>

When input is dumped as specified by `-dump-input=fail`, this patch
filters the dump to show only input lines that are the starting lines
of error diagnostics plus the number of contextual lines specified
`-dump-input-context` (defaults to 5).

When `-dump-input=always`, there might be not be any errors, so all
input lines are printed, as without this patch.

Here's some sample output with `-dump-input-context=3 -vv`:

```
<<<<<<
           .
           .
           .
          13: foo
          14: foo
          15: hello world
check:1       ^~~~~~~~~~~
          16: foo
check:2'0     X~~ error: no match found
          17: foo
check:2'0     ~~~
          18: foo
check:2'0     ~~~
          19: foo
check:2'0     ~~~
           .
           .
           .
          27: foo
check:2'0     ~~~
          28: foo
check:2'0     ~~~
          29: foo
check:2'0     ~~~
          30: goodbye word
check:2'0     ~~~~~~~~~~~~
check:2'1     ?            possible intended match
          31: foo
check:2'0     ~~~
          32: foo
check:2'0     ~~~
          33: foo
check:2'0     ~~~
           .
           .
           .
>>>>>>
```

Reviewed By: mehdi_amini, arsenm, jhenderson, rsmith, SjoerdMeijer, Meinersbur, lattner

Differential Revision: https://reviews.llvm.org/D82203
2020-07-10 11:02:10 -04:00
Alexandre Ganea
23cd70d71c [PDB] Fix out-of-bounds acces when sorting GSI buckets
When building in Debug on Windows-MSVC after b7402edce3, a lot of tests were failing because we were dereferencing an element past the end of HashRecords. This happened towards the end of the table, in unused slots.
2020-07-10 10:55:27 -04:00
Sam McCall
5fea54bc05 [clangd] Update semanticTokens support to reflect latest LSP draft
Summary: Mostly a few methods and message names have been renamed.

Reviewers: hokein

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D83556
2020-07-10 16:52:57 +02:00
Roman Lebedev
7103c87596 Reland "[InstCombine] Lower infinite combine loop detection thresholds""
This relands commit cd7f8051ac that was
reverted since lower threshold have successfully found an issue.
Now that the issue is fixed, let's wait until the next one is reported.

This reverts commit caa423eef0.
2020-07-10 17:49:16 +03:00
Roman Lebedev
2655a70a04 [InstCombine] After merging store into successor, queue prev. store to be visited (PR46661)
We can happen to have a situation with many stores eligible for transform,
but due to our visitation order (top to bottom), when we have processed
the first eligible instruction, we would not try to reprocess the previous
instructions that are now also eligible.

So after we've successfully merged a store that was second-to-last instruction
into successor, if the now-second-to-last instruction is also a such store
that is eligible, add it to worklist to be revisited.

Fixes https://bugs.llvm.org/show_bug.cgi?id=46661
2020-07-10 17:49:16 +03:00
Roman Lebedev
ef0ecb7b03 [NFCI][InstCombine] PR46661: multiple stores eligible for merging into successor - worklist issue
The testcase should pass with a single instcombine iteration.
2020-07-10 17:49:16 +03:00
Kevin P. Neal
523a8513f8 [FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support."
Use the new -fexperimental-strict-floating-point flag in more cases to
fix the arm and aarch64 bots.

Differential Revision: https://reviews.llvm.org/D80952
2020-07-10 10:34:15 -04:00
Nicolas Vasilache
56c638b5c1 [mlir][Linalg] Generalize Vectorization of Linalg contractions
This revision adds support for vectorizing named and generic contraction ops to vector.contract. Cases in which the memref is 0-D are special cased to emit std.load/std.store instead of vector.transfer. Relevant tests are added.

Differential revision: https://reviews.llvm.org/D83307
2020-07-10 10:28:34 -04:00
Haojian Wu
015a0faa5e [clangd] Fix hover crash on InitListExpr.
Fixes https://github.com/clangd/clangd/issues/455

Differential Revision: https://reviews.llvm.org/D83546
2020-07-10 16:18:16 +02:00
Nicolas Vasilache
22c8a08fd8 [mlir][Vector] Fold chains of ExtractOp
This revision adds folding to ExtractOp by simply concatenating the position attributes.
2020-07-10 09:32:02 -04:00
Daniel Grumberg
0555db0a5d Normalize default value for -triple correctly 2020-07-10 13:58:48 +01:00
Kevin P. Neal
d4ce862f2a Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support."
We currently have strict floating point/constrained floating point enabled
for all targets. Constrained SDAG nodes get converted to the regular ones
before reaching the target layer. In theory this should be fine.

However, the changes are exposed to users through multiple clang options
already in use in the field, and the changes are _completely_ _untested_
on almost all of our targets. Bugs have already been found, like
"https://bugs.llvm.org/show_bug.cgi?id=45274".

This patch disables constrained floating point options in clang everywhere
except X86 and SystemZ. A warning will be printed when this happens.

Use the new -fexperimental-strict-floating-point flag to force allowing
strict floating point on hosts that aren't already marked as supporting
it (X86 and SystemZ).

Differential Revision: https://reviews.llvm.org/D80952
2020-07-10 08:49:45 -04:00
David Green
e1135b486a Revert "[BasicAA] Enable -basic-aa-recphi by default"
This reverts commit af839a9618.

Some issues appear to be being caused by this. Reverting whilst we
investigate.
2020-07-10 13:43:54 +01:00
Sam McCall
86f1313424 [clangd] Config: If.PathExclude
Reviewers: hokein

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D83511
2020-07-10 14:31:02 +02:00
Victor Huang
118366dcb6 [PowerPC] Implement R_PPC64_REL24_NOTOC calls, callee also has no TOC
The PC Relative code allows for calls that are marked with the relocation
R_PPC64_REL24_NOTOC. This indicates that the caller does not have a valid TOC
pointer in R2 and does not require R2 to be restored after the call.

This patch is added to support local calls to callees tha also do not have a TOC.

Reviewed By: sfertile, MaskRay, stefanp

Differential Revision: https://reviews.llvm.org/D82816
2020-07-10 07:23:32 -05:00
Ulrich Weigand
4c5a93bd58 [ABI] Handle C++20 [[no_unique_address]] attribute
Many platform ABIs have special support for passing aggregates that
either just contain a single member of floatint-point type, or else
a homogeneous set of members of the same floating-point type.

When making this determination, any extra "empty" members of the
aggregate type will typically be ignored.  However, in C++ (at least
in all prior versions), no data member would actually count as empty,
even if it's type is an empty record -- it would still be considered
to take up at least one byte of space, and therefore make those ABI
special cases not apply.

This is now changing in C++20, which introduced the [[no_unique_address]]
attribute.  Members of empty record type, if they also carry this
attribute, now do *not* take up any space in the type, and therefore
the ABI special cases for single-element or homogeneous aggregates
should apply.

The C++ Itanium ABI has been updated accordingly, and GCC 10 has
added support for this new case.  This patch now adds support to
LLVM.  This is cross-platform; it affects all platforms that use
the single-element or homogeneous aggregate ABI special case and
implement this using any of the following common subroutines
in lib/CodeGen/TargetInfo.cpp:
  isEmptyField
  isEmptyRecord
  isSingleElementStruct
  isHomogeneousAggregate
2020-07-10 14:01:05 +02:00
Simon Pilgrim
b69e0f674f DomTreeUpdater::dump() - use const auto& iterator in for-range-loop.
Avoids unnecessary copies and silences clang tidy warning.
2020-07-10 12:47:15 +01:00
Nathan James
a25487fd8c [clang-tidy] Use Options priority in enum options where it was missing 2020-07-10 12:27:08 +01:00
Simon Pilgrim
9ce9831289 StackSafetyAnalysis.cpp - pass ConstantRange arg as const reference.
Avoids unnecessary copies and silences clang tidy warning - we do this in most places, there are just a few that were missed.
2020-07-10 12:13:34 +01:00
Simon Pilgrim
4cc26a44ca [X86][SSE] Use shouldUseHorizontalOp helper to determine whether to use (F)HADD. NFCI. 2020-07-10 12:13:34 +01:00
dstuttar
69a89b54c6 [NFC] Change isFPPredicate comparison to ignore lower bound
Summary:
Since changing the Predicate to be an unsigned enum, the lower bound check for
isFPPredicate no longer needs to check the lower bound, since
it will always evaluate to true.

Also fixed a similar issue in SIISelLowering.cpp by removing the need for
comparing to FIRST and LAST predicates

Added an assert to the isFPPredicate comparison to flag if the
FIRST_FCMP_PREDICATE is ever changed to anything other than 0, in which case the
logic will break.

Without this change warnings are generated in VS.

Change-Id: I358f0daf28c0628c7bda8ad4cab4e1757b761bab

Subscribers: arsenm, jvesely, nhaehnle, hiraditya, kerbowa, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D83540
2020-07-10 11:57:20 +01:00
Paul Walker
f78e6a3095 [SVE] Code generation for fixed length vector truncates.
Lower fixed length vector truncates to a sequence of SVE UZP1 instructions.

Differential Revision: https://reviews.llvm.org/D83395
2020-07-10 10:37:19 +00:00
Pavel Labath
d372a8e8bc [lldb/pecoff] Use a different llvm createBinary overload for parsing
Change the code the use the version which accepts a memory buffer,
instead of the one taking a file name.

This ensures we are not loading the file into memory twice
(ObjectFilePECOFF also loads a copy), reducing our memory footprint, as
well as enabling additional goodies in the future, like being able to
open files which don't exist on disk (D83512).
2020-07-10 11:57:11 +02:00
Haojian Wu
5f41ca48d1 [clang-tidy] More strict on matching the standard memset function in memset-usage check.
The check assumed the matched function call has 3 arguments, but the
matcher didn't guaranteed that.

Differential Revision: https://reviews.llvm.org/D83301
2020-07-10 11:42:35 +02:00
Florian Hahn
264ab1e2c8 [LV] Pick vector loop body as insert point for SCEV expansion.
Currently the DomTree is not kept up to date for additional blocks
generated in the vector loop, for example when vectorizing with
predication. SCEVExpander relies on dominance checks when looking for
existing instructions to re-use and in some cases that can lead to the
expander picking instructions that do not actually dominate their insert
point (e.g. as in PR46525).

Unfortunately keeping the DT up-to-date is a bit tricky, because the CFG
is only patched up after generating code for a block. For now, we can
just use the vector loop header, as this ensures the inserted
instructions dominate all uses in the vector loop. There should be no
noticeable impact on the generated code, as other passes should sink
those instructions, if profitable.

Fixes PR46525.

Reviewers: Ayal, gilr, mkazantsev, dmgreen

Reviewed By: dmgreen

Differential Revision: https://reviews.llvm.org/D83288
2020-07-10 10:37:12 +01:00
Mirko Brkusanin
cf40db21af [AMDGPU][GlobalISel] Fix G_AMDGPU_TBUFFER_STORE_FORMAT mapping
Add missing mappings and tablegen definitions for TBUFFER_STORE_FORMAT.

Differential Revision: https://reviews.llvm.org/D83240
2020-07-10 11:32:32 +02:00
Simon Pilgrim
9a3e8b11a8 extractConstantWithoutWrapping - use const APInt& returned by SCEVConstant::getAPInt()
Avoids unnecessary APInt copies and silences clang tidy warning.
2020-07-10 10:24:29 +01:00
Vitaly Buka
c06417b24d Fix check-all with -DLLVM_USE_SANITIZER=Address 2020-07-10 01:47:51 -07:00
Simon Pilgrim
77133cc1e2 [X86][AVX] Attempt to fold PACK(SHUFFLE(X,Y),SHUFFLE(X,Y)) -> SHUFFLE(PACK(X,Y)).
Truncations lowered as shuffles of multiple (concatenated) vectors often leave us with lane-crossing shuffles that feed a PACKSS/PACKUS, if both shuffles are fed from the same 2 vector sources, then we can PACK the sources directly and shuffle the result instead.

This is currently limited to whole i128 lanes in a 256-bit vector, but we can extend this if the need arises (but I'm not seeing many examples in real world code).
2020-07-10 09:33:27 +01:00
Valeriy Savchenko
00997d1cad [analyzer][tests] Fix zip unpacking
Differential Revision: https://reviews.llvm.org/D83374
2020-07-10 11:32:13 +03:00
Valeriy Savchenko
9c7ff0a4aa [analyzer][tests] Make test interruption safe
Differential Revision: https://reviews.llvm.org/D83373
2020-07-10 11:31:59 +03:00
Valeriy Savchenko
21bacc2154 [analyzer][tests] Measure peak memory consumption for every project
Differential Revision: https://reviews.llvm.org/D82967
2020-07-10 11:31:41 +03:00
Danila Kutenin
68c011aa08 [builtins] Optimize udivmodti4 for many platforms.
Summary:
While benchmarking uint128 division we found out that it has huge latency for small divisors

https://reviews.llvm.org/D83027

```
Benchmark                                                   Time(ns)        CPU(ns)     Iterations
--------------------------------------------------------------------------------------------------
BM_DivideIntrinsic128UniformDivisor<unsigned __int128>            13.0           13.0     55000000
BM_DivideIntrinsic128UniformDivisor<__int128>                     14.3           14.3     50000000
BM_RemainderIntrinsic128UniformDivisor<unsigned __int128>         13.5           13.5     52000000
BM_RemainderIntrinsic128UniformDivisor<__int128>                  14.1           14.1     50000000
BM_DivideIntrinsic128SmallDivisor<unsigned __int128>             153            153        5000000
BM_DivideIntrinsic128SmallDivisor<__int128>                      170            170        3000000
BM_RemainderIntrinsic128SmallDivisor<unsigned __int128>          153            153        5000000
BM_RemainderIntrinsic128SmallDivisor<__int128>                   155            155        5000000
```

This patch suggests a more optimized version of the division:

If the divisor is 64 bit, we can proceed with the divq instruction on x86 or constant multiplication mechanisms for other platforms. Once both divisor and dividend are not less than 2**64, we use branch free subtract algorithm, it has at most 64 cycles. After that our benchmarks improved significantly

```
Benchmark                                                   Time(ns)        CPU(ns)     Iterations
--------------------------------------------------------------------------------------------------
BM_DivideIntrinsic128UniformDivisor<unsigned __int128>            11.0           11.0     64000000
BM_DivideIntrinsic128UniformDivisor<__int128>                     13.8           13.8     51000000
BM_RemainderIntrinsic128UniformDivisor<unsigned __int128>         11.6           11.6     61000000
BM_RemainderIntrinsic128UniformDivisor<__int128>                  13.7           13.7     52000000
BM_DivideIntrinsic128SmallDivisor<unsigned __int128>              27.1           27.1     26000000
BM_DivideIntrinsic128SmallDivisor<__int128>                       29.4           29.4     24000000
BM_RemainderIntrinsic128SmallDivisor<unsigned __int128>           27.9           27.8     26000000
BM_RemainderIntrinsic128SmallDivisor<__int128>                    29.1           29.1     25000000
```

If not using divq instrinsics, it is still much better

```
Benchmark                                                   Time(ns)        CPU(ns)     Iterations
--------------------------------------------------------------------------------------------------
BM_DivideIntrinsic128UniformDivisor<unsigned __int128>            12.2           12.2     58000000
BM_DivideIntrinsic128UniformDivisor<__int128>                     13.5           13.5     52000000
BM_RemainderIntrinsic128UniformDivisor<unsigned __int128>         12.7           12.7     56000000
BM_RemainderIntrinsic128UniformDivisor<__int128>                  13.7           13.7     51000000
BM_DivideIntrinsic128SmallDivisor<unsigned __int128>              30.2           30.2     24000000
BM_DivideIntrinsic128SmallDivisor<__int128>                       33.2           33.2     22000000
BM_RemainderIntrinsic128SmallDivisor<unsigned __int128>           31.4           31.4     23000000
BM_RemainderIntrinsic128SmallDivisor<__int128>                    33.8           33.8     21000000
```

PowerPC benchmarks:

Was
```
BM_DivideIntrinsic128UniformDivisor<unsigned __int128>            22.3           22.3     32000000
BM_DivideIntrinsic128UniformDivisor<__int128>                     23.8           23.8     30000000
BM_RemainderIntrinsic128UniformDivisor<unsigned __int128>         22.5           22.5     32000000
BM_RemainderIntrinsic128UniformDivisor<__int128>                  24.9           24.9     29000000
BM_DivideIntrinsic128SmallDivisor<unsigned __int128>             394            394        2000000
BM_DivideIntrinsic128SmallDivisor<__int128>                      397            397        2000000
BM_RemainderIntrinsic128SmallDivisor<unsigned __int128>          399            399        2000000
BM_RemainderIntrinsic128SmallDivisor<__int128>                   397            397        2000000
```

With this patch
```
BM_DivideIntrinsic128UniformDivisor<unsigned __int128>            21.7           21.7     33000000
BM_DivideIntrinsic128UniformDivisor<__int128>                     23.0           23.0     31000000
BM_RemainderIntrinsic128UniformDivisor<unsigned __int128>         21.9           21.9     33000000
BM_RemainderIntrinsic128UniformDivisor<__int128>                  23.9           23.9     30000000
BM_DivideIntrinsic128SmallDivisor<unsigned __int128>              32.7           32.6     23000000
BM_DivideIntrinsic128SmallDivisor<__int128>                       33.4           33.4     21000000
BM_RemainderIntrinsic128SmallDivisor<unsigned __int128>           31.1           31.1     22000000
BM_RemainderIntrinsic128SmallDivisor<__int128>                    33.2           33.2     22000000
```

My email: danilak@google.com, I don't have commit rights

Reviewers: howard.hinnant, courbet, MaskRay

Reviewed By: courbet

Subscribers: steven.zhang, #sanitizers

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D81809
2020-07-10 09:59:16 +02:00
Diogo Sampaio
7bf168390f [BDCE] SExt -> ZExt when no sign bits is used and instruction has multiple uses
Summary: This allows to convert any SExt to a ZExt when we know none of the extended bits are used, specially in cases where there are multiple uses of the value.

Reviewers: dmgreen, eli.friedman, spatel, lebedev.ri, nikic

Reviewed By: lebedev.ri, nikic

Subscribers: hiraditya, dmgreen, craig.topper, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D60413
2020-07-10 08:34:53 +01:00
David Sherwood
da731894a2 [CodeGen] Replace calls to getVectorNumElements() in DAGTypeLegalizer::SetSplitVector
In DAGTypeLegalizer::SetSplitVector I have changed calls in the assert
from getVectorNumElements() to getVectorElementCount(), since this
code path works for both fixed and scalable vectors.

This fixes up one warning in the test:

  sve-sext-zext.ll

Differential Revision: https://reviews.llvm.org/D83196
2020-07-10 08:29:17 +01:00
Thomas Lively
043eaa9a4a [WebAssembly][NFC] Simplify vector shift lowering and add tests
This patch builds on 0d7286a652 by simplifying the code for detecting
splat values and adding new tests demonstrating the lowering of
splatted absolute value shift amounts, which are common in code
generated by Halide. The lowering is very bad right now, but
subsequent patches will improve it considerably. The tests will be
useful for evaluating the improvements in those patches.

Reviewed By: aheejin

Differential Revision: https://reviews.llvm.org/D83493
2020-07-10 00:18:59 -07:00
George Mitenkov
eb6b7c5d4f [MLIR][SPIRVToLLVM] Conversion of SPIR-V struct type without offset
This patch introduces type conversion for SPIR-V structs. Since
handling offset case requires thorough testing, it was left out
for now. Hence, only structs with no offset are currently
supported. Also, structs containing member decorations cannot
be translated.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D83403
2020-07-10 10:15:45 +03:00
David Sherwood
229dfb4728 [CodeGen] Replace calls to getVectorNumElements() in SelectionDAG::SplitVector
This patch replaces some invalid calls to getVectorNumElements() with calls
to getVectorMinNumElements() instead, since the code paths changed in this
patch work for both fixed and scalable vector types.

Fixes warnings in this test:

  sve-sext-zext.ll

Differential Revision: https://reviews.llvm.org/D83203
2020-07-10 08:11:30 +01:00
Muhammad Omair Javaid
a65da5f592 [LLDB] Update AArch64 Dwarf and EH frame register numbers
This patch updates ARM64_ehframe_Registers.h and ARM64_DWARF_Registers.h
with latest register numbers in line with AArch64 SVE support.

For refernce take a look at "DWARF for the ARM® 64-bit Architecture (AArch64)
with SVE support" manual from Arm.
Version used: abi_sve_aadwarf_100985_0000_00_en.pdf
2020-07-10 11:45:39 +05:00
Daniel Grumberg
50f24331fd Add diagnostic option backing field for -fansi-escape-codes
Summary:
Keep track of -fansi-escape-codes in DiagnosticOptions and move the
option to the new option parsing system.

Depends on D82860

Reviewers: Bigcheese

Subscribers: dexonsmith, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D82874
2020-07-10 07:26:56 +01:00
Zakk Chen
04b9a46c84 [RISCV] Refactor FeatureRVCHints to make ProcessorModel more intuitive
Reviewers: luismarques, asb, evandro

Reviewed By: asb, evandro

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77030
2020-07-09 23:07:39 -07:00
Nathan Ridge
98d763ad05 [clangd] Factor out some helper functions related to heuristic resolution in TargetFinder
Summary:
Two helpers are introduced:

 * Some of the logic previously in TargetFinder::Visit*() methods is
   factored out into resolveDependentExprToDecls().

 * Some of the logic in getMembersReferencedViaDependentName() is
   factored out into resolveTypeToRecordDecl().

D82739 will build on this and use these functions in new ways.

Reviewers: hokein

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D83371
2020-07-10 01:58:34 -04:00
SharmaRithik
e71c7b593a [CodeMoverUtils] Move OrderedInstructions to CodeMoverUtils
Summary: This patch moves OrderedInstructions to CodeMoverUtils as It was
the only place where OrderedInstructions is required.
Authored By: RithikSharma
Reviewer: Whitney, bmahjour, etiotto, fhahn, nikic
Reviewed By: Whitney, nikic
Subscribers: mgorny, hiraditya, llvm-commits
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D80643
2020-07-10 11:22:43 +05:30