| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
for the `RTHwasan_dynamic` target.
Differential Revision: https://reviews.llvm.org/D49178
llvm-svn: 336944
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Not all programs want section ordering when compiled with LTO.
In particular, the Linux kernel is very sensitive when it comes to linking, and
doesn't boot when each function is placed in its own sections.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D48756
llvm-svn: 336943
|
| |
|
|
|
|
| |
The test for a function with an if block in a single line (https://bugs.llvm.org/show_bug.cgi?id=38065) will be moved to a separate test.
llvm-svn: 336942
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This allows counters associated with unused functions to be
dead-stripped along with their functions. This approach is the same one
we used for PC tables.
Fixes an issue where LLD removes an unused PC table but leaves the 8-bit
counter.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, hiraditya, kcc
Differential Revision: https://reviews.llvm.org/D49264
llvm-svn: 336941
|
| |
|
|
|
|
|
| |
Add the two options -ppc-vsr-nums-as-vr and -ppc-asm-full-reg-names to
the __float128 tests. Then modify the tests as required.
llvm-svn: 336940
|
| |
|
|
| |
llvm-svn: 336939
|
| |
|
|
|
|
|
|
|
|
| |
observe a failure to select EVEX instructions.
The one I noticed is sqrtsss/sd, but there could be others.
I had to add a couple new tests that don't have insertelement in there to catch this on the fast-isel path. Otherwise we trigger an abort and use SelectionDAG.
llvm-svn: 336938
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diagnostic triggers when -fsanitize=object-size is explicitly
specified but will be a no-op (i.e, at -O0).
This diagnostic should not fail a -Werror build because it's just an
explanatory note to the user. It's not always actionable.
For example, a user may not be able to simply disable object-size,
because they want it enabled in optimized builds.
rdar://42128447
llvm-svn: 336937
|
| |
|
|
| |
llvm-svn: 336936
|
| |
|
|
|
|
|
| |
The piece above probably has the same problem, but I need
to try to come up with a test for it.
llvm-svn: 336935
|
| |
|
|
|
|
|
|
|
|
| |
pipeline dependencies on StackProtector; NFC"
This was triggering pass scheduling failures.
This reverts commit r336929.
llvm-svn: 336934
|
| |
|
|
| |
llvm-svn: 336933
|
| |
|
|
|
|
|
| |
Since we now have a test that requires LLD, make sure it is built before
that test runs.
llvm-svn: 336932
|
| |
|
|
|
|
| |
deduction.
llvm-svn: 336931
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This revision disallows lambdas in template parameters, as reported in PR33696.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37442
llvm-svn: 336930
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PrologEpilogInserter and StackColoring depend on the StackProtector analysis
being alive from the point it is run until PEI, which requires that they are all
scheduled in the same FunctionPassManager. Inserting a (machine) ModulePass
between StackProtector and PEI results in these passes being in separate
FunctionPassManagers and the StackProtector is not available for PEI.
PEI and StackColoring don't use much information from the StackProtector pass,
so transfering the required information to MachineFrameInfo is cleaner than
keeping the StackProtector pass around. This commit moves the SSP layout
information to MFI instead of keeping it in the pass.
This patch set (D37580, D37581, D37582, D37583, D37584, D37585, D37586, D37587)
is a first draft of the pagerando implementation described in
http://lists.llvm.org/pipermail/llvm-dev/2017-June/113794.html.
Patch by Stephen Crane <sjc@immunant.com>
Differential Revision: https://reviews.llvm.org/D49256
llvm-svn: 336929
|
| |
|
|
| |
llvm-svn: 336928
|
| |
|
|
|
|
|
|
|
|
|
|
| |
support for split DWARF
and no use of DW_FORM_rnglistx with the DW_AT_ranges attribute.
Reviewer: aprantl
Differential Revision: https://reviews.llvm.org/D49214
llvm-svn: 336927
|
| |
|
|
|
|
|
| |
The lld feature is never available for libFuzzer tests, so
gc-sections.test never actually runs.
llvm-svn: 336926
|
| |
|
|
|
|
|
|
| |
from the instruction.
We were accidentally connecting it to result 0 instead of result 1. This was caught by the machine verifier that noticed the flags were dead, but we were using them somehow. I'm still not clear what actually happened downstream.
llvm-svn: 336925
|
| |
|
|
|
|
|
|
| |
x86_sse_cvttss2si and similar intrinsics.
This should fix a machine verifier error.
llvm-svn: 336924
|
| |
|
|
| |
llvm-svn: 336923
|
| |
|
|
|
|
| |
reference with a braced initializer list
llvm-svn: 336922
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This option appears to have been dropped as part of the refactoring in
r331663. Unfortunately, if we want to use llvm-strip as a drop-in
replacement for strip, this option should still be available.
Reviewers: alexshap
Reviewed By: alexshap
Subscribers: meikeb, kongyi, chh, jakehehrlich, llvm-commits, pirama
Differential Revision: https://reviews.llvm.org/D49226
llvm-svn: 336921
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LangOpts"
This reverts commit f40124d4f05ecf4f880cf4e8f26922d861f705f3 / r336660.
This change shouldn't be affecting `@import` behavior, but turns out it is:
https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-osx-master-next/2800/consoleFull#-12570166563122a513-f36a-4c87-8ed7-cbc36a1ec144
Working on a reduced testcase for this, reverting in the meantime.
rdar://problem/42102222
llvm-svn: 336920
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: SQL is a common acronym.
Reviewers: Wizard, hokein
Reviewed By: Wizard, hokein
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49190
llvm-svn: 336919
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
checks
Corrupted minidumps was leading to unpredictable behavior.
This change adds explicit consistency checks for the minidump early on. The
checks are not comprehensive but they should catch obvious structural violations:
streams with type == 0
duplicate streams (same type)
overlapping streams
truncated minidumps
Another early check is to make sure we actually support the minidump architecture
instead of crashing at a random place deep inside LLDB.
Differential Revision: https://reviews.llvm.org/D49202
llvm-svn: 336918
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
[[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]]
As discussed in https://reviews.llvm.org/D49179#1158957 and later,
the IR can be improved:
https://rise4fun.com/Alive/gBf
^ that pattern will be produced by Implicit Integer Truncation sanitizer,
https://reviews.llvm.org/D48958
https://bugs.llvm.org/show_bug.cgi?id=21530
in signed case, therefore it is probably a good idea to improve it.
But as it looks from these tests,
i think we want to revert at least some cases in DAGCombine.
Reviewers: spatel, craig.topper, RKSimon, javed.absar
Reviewed By: spatel
Subscribers: kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D49247
llvm-svn: 336917
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch eliminates some redundancy in iterating across Listeners for the
Instruction and Stall HWEvents, by introducing a template onEvent routine.
This change was suggested by @courbet in https://reviews.llvm.org/D48576. I
hope that this patch addresses that suggestion appropriately. I do like this
change better than what we had previously.
Reviewers: andreadb, courbet, RKSimon
Reviewed By: andreadb, courbet
Subscribers: javed.absar, tschuett, gbedwell, llvm-commits, courbet
Differential Revision: https://reviews.llvm.org/D48672
llvm-svn: 336916
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Patch fixes the next problems.
1. Removes unused functions from omptarget_nvptx_ThreadPrivateContext
class + simplified data members.
2. Fixed calculation of loop boundaries for dynamic loops with static
scheduling.
3. Introduced saving/restoring of the dynamic loop boundaries to support
several nested parallel dynamic loops.
Reviewers: grokos
Subscribers: guansong, kkwli0, openmp-commits
Differential Revision: https://reviews.llvm.org/D49241
llvm-svn: 336915
|
| |
|
|
| |
llvm-svn: 336914
|
| |
|
|
|
|
| |
These instructions are added to AArch64 only.
llvm-svn: 336913
|
| |
|
|
|
|
|
|
|
|
|
|
| |
While that fold is clearly not happening [anymore],
we do now have separate test cases for these cases,
so we should be ok to slightly adjust these tests
to not potentially loose test coverage.
As suggested by Hiroshi Yamauchi in
https://reviews.llvm.org/D49179#1159345
llvm-svn: 336912
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A complementary fold to D49179.
https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/Rny
Caveat: one more thing in `test/Transforms/InstCombine/icmp-logical.ll` breaks.
Reviewers: spatel, craig.topper
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49205
llvm-svn: 336911
|
| |
|
|
| |
llvm-svn: 336910
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgorny, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49142
llvm-svn: 336909
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have located a bug in AssemblyWriter::printModuleSummaryIndex(). This
function outputs path strings incorrectly. Backslashes in the strings
are not correctly escaped.
Consequently, if a path name contains a backslash followed by two
hexadecimal characters, the sequence is incorrectly interpreted when the
output is read by another component. This mangles the path and results
in error.
This patch fixes this issue by calling printEscapedString() to output
the module paths.
Patch by Chris Jackson.
Differential Revision: https://reviews.llvm.org/D49090
llvm-svn: 336908
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These tests would fail with -verify-machineinstrs because the MI
generated from the IR would be merged with the one already in the MIR
files, and we get the following error:
```
*** Bad machine code: Function has NoVRegs property but there are VReg operands ***
- function: f
```
Differential Revision: https://reviews.llvm.org/D49191
llvm-svn: 336907
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure if this fix is the right thing to do, but it seemed to me
that PATCHABLE_RET and PATCHABLE_TAIL_CALL don't have any defs.
Running the following:
```
LLVM_ENABLE_MACHINE_VERIFIER=1 ./build/bin/llvm-lit -v -a test/CodeGen/X86/xray-*
```
results in the following tests to fail (along others):
```
LLVM :: CodeGen/X86/xray-attribute-instrumentation.ll
LLVM :: CodeGen/X86/xray-custom-log.ll
LLVM :: CodeGen/X86/xray-log-args.ll
LLVM :: CodeGen/X86/xray-loop-detection.ll
LLVM :: CodeGen/X86/xray-multiplerets-in-blocks.mir
LLVM :: CodeGen/X86/xray-section-group.ll
LLVM :: CodeGen/X86/xray-selective-instrumentation.ll
LLVM :: CodeGen/X86/xray-tail-call-sled.ll
LLVM :: CodeGen/X86/xray-typed-event-log.ll
```
The errors are:
```
*** Bad machine code: Explicit definition must be a register ***
- function: fn
- basic block: %bb.0 (0x7fa31a84d908)
- instruction: PATCHABLE_RET 2560, $eax
- operand 0: 2560
```
and
```
*** Bad machine code: Explicit definition must be a register ***
- function: caller
- basic block: %bb.0 (0x7fbff3044108)
- instruction: PATCHABLE_TAIL_CALL 3009, @callee, <regmask $bh $bl $bp $bph $bpl $bx $ebp $ebx $hbp $hbx $rbp $rbx $r12 $r13 $r14 $r15 $r12b $r13b $r14b $r15b $r12bh $r13bh $r14bh $r15bh $r12d $r13d $r14d $r15d $r12w $r13w $r14w $r15w $r12wh and 3 more...>, implicit $rsp, implicit $ssp, implicit $rsp, implicit $ssp, implicit $edi
- operand 0: 3009
```
Differential Revision: https://reviews.llvm.org/D49187
llvm-svn: 336906
|
| |
|
|
|
|
|
|
|
|
|
| |
The list duplicates information already available in the parent
directory so use that instead. It is unclear to me why we need
to spell out the dependencies explicitly but fixing that should
be done in a separate patch.
Differential Revision: https://reviews.llvm.org/D49177
llvm-svn: 336905
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
`lib/sanitizer_common`.
The variable name `SANITIZER_HEADERS` is already used for the list of
public headers in `include/CMakeLists.txt`. Although the previous
implementation worked it's probably best to avoid shadowing global
variables to avoid confusion.
Differential Revision: https://reviews.llvm.org/D49176
llvm-svn: 336904
|
| |
|
|
|
|
|
|
|
|
| |
canWidenShuffleElements can do a better job if given a mask with ZeroableElements info. Apparently, ZeroableElements was being only used to identify AllZero candidates, but possibly we could plug it into more shuffle matchers.
Original Patch by Zvi Rackover @zvi
Differential Revision: https://reviews.llvm.org/D42044
llvm-svn: 336903
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49222
llvm-svn: 336902
|
| |
|
|
|
|
|
|
|
|
|
| |
anonymous namespace
As the code for the checker grew, it became increasinly difficult to see
whether a function was global or statically defined. In this patch,
anything that isn't a type declaration or definition was moved out of the
anonymous namespace and is marked as static.
llvm-svn: 336901
|
| |
|
|
|
|
|
|
|
|
| |
Noticed while updating D42044, lowerV2X128VectorShuffle can improve the shuffle mask with the zeroable data to create a target shuffle mask to recognise more 'zero upper 128' patterns.
NOTE: lowerV4X128VectorShuffle could benefit as well but the code needs refactoring first to discriminate between SM_SentinelUndef and SM_SentinelZero for negative shuffle indices.
Differential Revision: https://reviews.llvm.org/D49092
llvm-svn: 336900
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Bodies are logged at VERBOSE level (since r336785), tweak the formatting.
Reviewers: hokein
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49224
llvm-svn: 336899
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
definition in parameters
Summary:
Importing a function having a struct definition in the parameter list
causes a crash in the importer via infinite recursion. This patch avoids
the crash and reports such functions as not supported. Unit tests make
sure that normal struct definitions inside function bodies work normally
on the other hand and LLDB-like type imports also do.
Reviewers: a.sidorin, martong
Differential Revision: https://reviews.llvm.org/D47946
Patch by Zoltan Gera!
llvm-svn: 336898
|
| |
|
|
|
|
|
|
|
| |
We no longer care about the order of blocks in these collections,
so can change to SmallPtrSets, making contains checks quicker.
Differential revision: https://reviews.llvm.org/D49060
llvm-svn: 336897
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Generalize the creation of Decl nodes during Import. With this patch we do the
same things after and before a new AST node is created (::Create) The import
logic should be really simple, we create the node, then we mark that as
imported, then we recursively import the parts for that node and then set them
on that node. However, the AST is actually a graph, so we have to handle
circles. If we mark something as imported (`MapImported()`) then we return with
the corresponding `To` decl whenever we want to import that node again, this way
circles are handled. In order to make this algorithm work we must ensure
things, which are handled in the generic CreateDecl<> template:
* There are no `Import()` calls in between any node creation (::Create)
and the `MapImported()` call.
* Before actually creating an AST node (::Create), we must check if
the Node had been imported already, if yes then return with that one.
One very important case for this is connected to templates: we may
start an import both from the templated decl of a template and from
the template itself.
Now, the virtual `Imported` function is called in `ASTImporter::Impor(Decl *)`,
but only once, when the `Decl` is imported. One point of this refactor is to
separate responsibilities. The original `Imported()` had 3 responsibilities:
- notify subclasses when an import happened
- register the decl into `ImportedDecls`
- initialise the Decl (set attributes, etc)
Now all of these are in separate functions:
- `Imported`
- `MapImported`
- `InitializeImportedDecl`
I tried to check all the clients, I executed tests for `ExternalASTMerger.cpp`
and some unittests for lldb.
Reviewers: a.sidorin, balazske, xazax.hun, r.stahl
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47632
llvm-svn: 336896
|
| |
|
|
| |
llvm-svn: 336895
|