| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Noticed this when I tried to port the Protocol.h parsers.
And tests for the inspect API, which caught a small bug.
Reviewers: ioeric
Subscribers: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D40399
llvm-svn: 319157
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The entire algorithm operates per basic-block, so for cache locality
it should be better to re-optimize a basic-block immediately rather than
in a separate loop.
I don't have performance measurements.
Change-Id: I85106570bd623c4ff277faaa50ee43258e1ddcc5
Reviewers: arsenm, rampitec
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D40344
llvm-svn: 319156
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The PeepholeOptimizer pass calls this function solely based on checking
DefMI->isMoveImmediate(), which only checks the MoveImm bit of the
instruction description. So it's up to FoldImmediate itself to properly
check that DefMI *actually* moves from an immediate.
I don't have a separate test case for this, but the next patch introduces
a test case which happens to crash without this change.
This error is caught by the assertion in MachineOperand::getImm().
Change-Id: I88e7cdbcf54d75e1a296822e6fe5f9a5f095bbf8
Reviewers: arsenm, rampitec
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D40342
llvm-svn: 319155
|
| |
|
|
|
|
|
|
|
|
|
| |
discarded sections."
and r319051, "Add a missing test."
r319008 broke the LTO bots;
r319051 depends on changes in r319008.
llvm-svn: 319154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we use a set of pairs to cache responces like `CompareValueComplexity(X, Y) == 0`. If we had
proved that `CompareValueComplexity(S1, S2) == 0` and `CompareValueComplexity(S2, S3) == 0`,
this cache does not allow us to prove that `CompareValueComplexity(S1, S3)` is also `0`.
This patch replaces this set with `EquivalenceClasses` that merges Values into equivalence sets so that
any two values from the same set are equal from point of `CompareValueComplexity`. This, in particular,
allows us to prove the fact from example above.
Differential Revision: https://reviews.llvm.org/D40429
llvm-svn: 319153
|
| |
|
|
| |
llvm-svn: 319152
|
| |
|
|
|
|
|
|
|
|
|
| |
This allows grouping all sections like ".ctors.12345" into ".ctors".
For MinGW, the numerical values for such ctors are all zero-padded,
so a lexical sort is good enough.
Differential Revision: https://reviews.llvm.org/D40408
llvm-svn: 319151
|
| |
|
|
|
|
|
|
|
|
|
| |
The priorities in the section name suffixes are zero padded,
allowing the linker to just do a lexical sort.
Add zero padding for .ctors sections in ELF as well.
Differential Revision: https://reviews.llvm.org/D40407
llvm-svn: 319150
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we use a set of pairs to cache responces like `CompareSCEVComplexity(X, Y) == 0`. If we had
proved that `CompareSCEVComplexity(S1, S2) == 0` and `CompareSCEVComplexity(S2, S3) == 0`,
this cache does not allow us to prove that `CompareSCEVComplexity(S1, S3)` is also `0`.
This patch replaces this set with `EquivalenceClasses` any two values from the same set are equal from
point of `CompareSCEVComplexity`. This, in particular, allows us to prove the fact from example above.
Differential Revision: https://reviews.llvm.org/D40428
llvm-svn: 319149
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Streamlines the output under Python 3.x.
Before:
```
b'Enabled checks:\n clang-analyzer-apiModeling.google.GTest\n ...
```
After:
```
Enabled checks:
clang-analyzer-apiModeling.google.GTest
...
```
Reviewers: cfe-commits, alexfh
Reviewed By: alexfh
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D37482
Change-Id: I6287104bc73926ae6d0f66c15c250c3cb44bee33
llvm-svn: 319148
|
| |
|
|
|
|
|
|
|
|
|
|
| |
control flow to successors
This is to address a problem similar to those in D37460 for Scalar PRE. We should not
PRE across an instruction that may not pass execution to its successor unless it is safe
to speculatively execute it.
Differential Revision: https://reviews.llvm.org/D38619
llvm-svn: 319147
|
| |
|
|
|
|
|
|
| |
This reverts commit r319073.
Bot fails with a mismatch that looks like pygments-generated HTML.
llvm-svn: 319146
|
| |
|
|
| |
llvm-svn: 319145
|
| |
|
|
|
|
|
|
|
| |
Fast-isel routines need to bail out in the case that fast-isel
fails on the operands.
This fixes https://bugs.llvm.org/show_bug.cgi?id=35064
llvm-svn: 319144
|
| |
|
|
| |
llvm-svn: 319143
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unoptimized IR can have linear sequences of stores to an array, where the
initial GEP for the first store is formed from the pointer to the array, and the
GEP for each store after the first is formed from the previous GEP with some
offset in an inductive fashion.
The (large) resulting DAG when analyzed by DAGCombine undergoes an excessive
number of combines as each store node is examined every time its' offset node
is combined with any child of the offset. One of the transformations is
findBetterNeighborChains which assists MergeConsecutiveStores. The former
relies on repeated chain walking to do its' work, however MergeConsecutiveStores
is disabled at O0 which makes the transformation redundant.
Any optimization level other than O0 would invoke InstCombine which would
resolve the chain of GEPs into flat base + offset GEP for each store which
does not exhibit the repeated examination of each store to the array.
Disabling this optimization fixes an excessive compile time issue (30~ minutes
for the test case provided) at O0.
Reviewers: niravd, craig.topper, t.p.northover
Differential Revision: https://reviews.llvm.org/D40193
llvm-svn: 319142
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes cases where we wouldn't perform various register operand
checks just because we didn't happen to have a definition in the
MCInstrDesc. This changes the code to only skip the tests that actually
depend on the MCInstrDesc definition.
This makes the machine verifier spot the problem from
https://llvm.org/PR33071 after the pass that actually caused it.
llvm-svn: 319141
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Additional checks for phi operands:
- first operand should be a virtual register def. It should not be
tied, implicit, internalread, earlyclobber or a read.
- The other operands should be register/mbb operands next to each other
- The register operands should not be implicit, internalread,
earlyclobber, debug or tied.
- We can perform most of the PHI checks even for unreachable blocks.
llvm-svn: 319140
|
| |
|
|
| |
llvm-svn: 319139
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40530
llvm-svn: 319138
|
| |
|
|
|
|
| |
We won't see the temp file no more.
llvm-svn: 319137
|
| |
|
|
|
|
| |
under AVX512.
llvm-svn: 319136
|
| |
|
|
|
|
| |
bitcast-int-to-vector-bool-zext.ll.
llvm-svn: 319135
|
| |
|
|
|
|
|
| |
This moves the TempFile implementation so that it can use system
specific code.
llvm-svn: 319134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
sections." with a fix for debug sections.
If /debug was not specified, readSection will return a null
pointer for debug sections. If the debug section is associative with
another section, we need to make sure that the section returned from
readSection is not a null pointer before adding it as an associative
section.
Differential Revision: https://reviews.llvm.org/D40533
llvm-svn: 319133
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Formatting needs to be done only once. Ran check-lldb and nothing changes.
Reviewers: clayborg, davide
Reviewed By: clayborg, davide
Subscribers: zturner, davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D40519
llvm-svn: 319132
|
| |
|
|
|
|
|
|
|
| |
Revert "[SROA] Propagate !range metadata when moving loads."
Revert "[Mem2Reg] Clang-format unformatted parts of this file. NFCI."
Davide says they broke a bot.
llvm-svn: 319131
|
| |
|
|
|
|
|
|
|
|
| |
https://llvm.org/PR32578
I simplified and converted the reproducer into a lit test.
Patch by Vedant Kumar!
llvm-svn: 319130
|
| |
|
|
|
|
|
| |
This adds ways to control use of WebAssembly's new nontrapping-fptoint
feature.
llvm-svn: 319129
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds code to protect WebAssembly's `trunc_s` family of opcodes
from values outside their domain. Even though such conversions have
full undefined behavior in C/C++, LLVM IR's `fptosi` and `fptoui` do
not, and only return undef.
This also implements the proposed non-trapping float-to-int conversion
feature and uses that instead when available.
llvm-svn: 319128
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we mark every shared symbol as STB_WEAK.
That is a hack to make it easy to decide when a .so is needed or not
because of a reference to a given symbol.
That hack leaks when we create copy relocations as shown by the update
to relocation-copy-alias.s.
This patch stores the original binding when we first read a shared
symbol. We still have to update the binding to weak if we see a weak
undef, but I find the logic easier to read where it is now.
llvm-svn: 319127
|
| |
|
|
|
|
|
|
| |
Fixes PR35416.
https://bugs.llvm.org/show_bug.cgi?id=35416
llvm-svn: 319126
|
| |
|
|
| |
llvm-svn: 319125
|
| |
|
|
|
|
|
|
| |
block. NFCI
These lines all exist identically either under SSE2, AVX2 or AVX512. Given that VLX implies all of those, these aren't providing anything new.
llvm-svn: 319124
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
object is sufficiently aligned.
r303175 annotated field unwindHeader of __cxa_exception with attribute
'aligned' to ensure the thrown object following the __cxa_exception
header was sufficiently aligned. This caused changes in the field
offsets of __cxa_exception relative to the start of the thrown object,
which was an ABI breaking change for some clients.
Instead of annotating field unwindHeader, this commit inserts extra
space before the header. This ensures the thrown object following the
header is sufficiently aligned without changing the field offsets, thus
avoiding any ABI breakages.
rdar://problem/25364625
rdar://problem/35556163
llvm-svn: 319123
|
| |
|
|
|
|
| |
These same calls exist a few lines down.
llvm-svn: 319122
|
| |
|
|
|
|
| |
For now this only changes the handle Access.
llvm-svn: 319121
|
| |
|
|
|
|
|
|
|
|
| |
target's preferred result type.
With AVX512 vXi1 types are legal so we shouldn't be extending them.
This change is similar to existing code in the zext(setcc) combine.
llvm-svn: 319120
|
| |
|
|
|
|
| |
implementing manually.
llvm-svn: 319119
|
| |
|
|
|
|
|
| |
This will allow a future F_Delete flag to be specified when we want
the file to be automatically deleted on close.
llvm-svn: 319117
|
| |
|
|
|
|
|
| |
cl interprets this option to mean enable every supported warning, which
is what Clang's -Weverything flag does.
llvm-svn: 319116
|
| |
|
|
|
|
|
|
|
| |
"offset" declared in a macro may shadow a variable with the same name
in the caller which is used in a macro argument. We are quite lucky
that it does not actually happen, but rename the variable anyway to
be on the safe side.
llvm-svn: 319115
|
| |
|
|
|
|
|
| |
After r319004, the expected failure on ppc64 manifests as an infinite
loop.
llvm-svn: 319114
|
| |
|
|
|
|
|
|
|
|
|
| |
This is also consistent with SymVector that exists in COFF port
and soon to be added to the wasm port.
Split off as part of https://reviews.llvm.org/D40371
Differential Revision: https://reviews.llvm.org/D40525
llvm-svn: 319113
|
| |
|
|
| |
llvm-svn: 319112
|
| |
|
|
|
|
|
|
| |
types.
Patch by Oleg Smolsky
llvm-svn: 319111
|
| |
|
|
|
|
|
|
| |
looking at larger than 512-bit vectors.
Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added.
llvm-svn: 319110
|
| |
|
|
|
|
|
|
|
| |
LLVM runtimes rely on LLVM_HOST_TRIPLE being set in their builds
and tests so make sure it's being passed down.
Differential Revision: https://reviews.llvm.org/D40515
llvm-svn: 319109
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40510
llvm-svn: 319108
|
| |
|
|
|
|
|
|
|
|
| |
We introduce a new variable LLVM_ENABLE_RUNTIMES which works
similarly to LLVM_ENABLE_PROJECTS and allows specifying runtimes
that will be enabled in the runtimes build.
Differential Revision: https://reviews.llvm.org/D40233
llvm-svn: 319107
|