| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add comments to help readers avoid having to read tablegen backends to
understand the code. Also remove unecessary breaks from the output.
Reviewers: dschuff, aheejin
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51371
llvm-svn: 340864
|
|
|
|
| |
llvm-svn: 340863
|
|
|
|
|
|
|
|
|
| |
The original motivating example uses a 64-bit add, so the carry
is used. Insert a copy from VCC. This may allow shrinking of
the used carry instruction. At worst, we are replacing a
mov to materialize the constant with a copy of vcc.
llvm-svn: 340862
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: aheejin
Subscribers: dschuff, sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51367
llvm-svn: 340861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Patch By: metzman
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 340860
|
|
|
|
|
|
|
|
|
| |
This needs to be done in the SSA fold operands
pass to be effective, so there is a bit of overlap
with SIShrinkInstructions but I don't think this
is practically avoidable.
llvm-svn: 340859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The updated tests were previously infallible because the SIMD bitwise
operations do not contain vector types in their names.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51369
llvm-svn: 340858
|
|
|
|
|
|
| |
Implementation and tests.
llvm-svn: 340857
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The Linux/BSD system call interfaces report errors differently, use the
internal_iserror() function to correctly check errors on either.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: delcypher, llvm-commits, #sanitizers, krytarowski, kcc, devnexen
Differential Revision: https://reviews.llvm.org/D51368
llvm-svn: 340856
|
|
|
|
| |
llvm-svn: 340855
|
|
|
|
|
|
| |
emitted ealier.
llvm-svn: 340854
|
|
|
|
|
|
|
| |
Avoid hyperlinear cost of inlining MERGE_VALUE node by constructing
temporary vector and doing a single replacement.
llvm-svn: 340853
|
|
|
|
|
|
|
| |
When making multiple updates to the same SDNode, recompute node
divergence only once after all changes have been made.
llvm-svn: 340852
|
|
|
|
|
|
|
| |
Check correct SDNode when deciding if we should update the divergence
property.
llvm-svn: 340851
|
|
|
|
| |
llvm-svn: 340850
|
|
|
|
|
|
|
|
|
| |
It seems like an oversight that this check was not always enabled for
on-device or device simulator targets.
Differential Revision: https://reviews.llvm.org/D51239
llvm-svn: 340849
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: tlively
Subscribers: dschuff, sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51366
llvm-svn: 340848
|
|
|
|
|
|
|
| |
This patch adds an example on how to generate a Chrome Trace Viewer
loadable trace from an XRay trace.
llvm-svn: 340847
|
|
|
|
|
|
| |
rL340842 contained the wrong version of the check lines.
llvm-svn: 340846
|
|
|
|
|
|
| |
This is dead code because lld -flavor old-gnu was removed in 2016 by rLLD262158.
llvm-svn: 340845
|
|
|
|
|
|
|
|
| |
These instructions were added on the PentiumPro along with CMOV.
This was already comprehended by the lowering process which should emit an alternate sequence using FCOM and FNSTW. This just makes it an explicit error if that doesn't work for some reason.
llvm-svn: 340844
|
|
|
|
|
|
|
| |
Add `xray_mode=xray-basic` to the list of options in the "further
exploration" section of the doc.
llvm-svn: 340843
|
|
|
|
| |
llvm-svn: 340842
|
|
|
|
|
|
|
| |
Patch by Eugene Birukov <eugenebi@microsoft.com>
Differential Revision: https://reviews.llvm.org/D49685
llvm-svn: 340841
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnose buildbot failures
Summary:
Right now this test is failing on the builtbots on Windows but we have a very similar setup where the test passes. The test is meant to test that specifying a timeout works correctly by running an infnite loop and having it timeout - on the buildbot, the infinite loop doesn't actually execute. This change runs all of the tests in the set using an internal shell rather than an external shell. I expect this will make the test pass which means that either the way the external shell is invoked or the external shell setup on the buildbots is not correct. Regardless of whether the test passes with this change, we'll need to undo this change and have a real fix.
@gkistanova was able to get logs from the buildbot to rule out a number of theories as to why this test is failing, but they didn't have enough information to confirm exactly what the issue is. The purpose of this change is to narrow it down, but if someone has a local repro and can aid in debugging, that would make it much speedier (and less prone to making the bots fail).
Reviewers: gkistanova, asmith, zturner, modocache, rnk, delcypher
Reviewed By: rnk
Subscribers: delcypher, llvm-commits, gkistanova
Differential Revision: https://reviews.llvm.org/D51326
llvm-svn: 340840
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For assembly input files, generate debug info even when the .file
directive is present, provided it does not include a file-number
argument. Fixes PR38695.
Reviewers: probinson, sidneym
Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D51315
llvm-svn: 340839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This greatly reduces the time to read 'compile_commands.json'.
For Chromium on my machine it's now 0.7 seconds vs 30 seconds before the
change.
Reviewers: sammccall, jfb
Reviewed By: sammccall
Subscribers: mgrang, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D51314
llvm-svn: 340838
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
predicates
CodeGenDAGPatterns::GenerateVariants is a costly function in many tblgen commands (33.87% of the total runtime of x86 -gen-dag-isel), and due to the O(N^2) nature of the function, there are a high number of repeated comparisons of the pattern's vector<Predicate>.
This initial patch at least avoids repeating these comparisons for every Variant in a pattern. I began investigating caching all the matches before entering the loop but hit issues with how best to store the data and how to update the cache as patterns were added.
Saves around 15secs in debug builds of x86 -gen-dag-isel.
Differential Revision: https://reviews.llvm.org/D51035
llvm-svn: 340837
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although the benchmark regex-related build issue seems to be
fixed, it appears that benchmark library triggers some stage 2 clang-cl
bugs:
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/13495/steps/build%20stage%202/logs/stdio
The only sensible option now is to prevent benchmark library from
building in the default configuration.
llvm-svn: 340836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch replaces the manual lock/unlock calls for gaining exclusive access to the disassembler with
a RAII-powered access scope. This should prevent that we somehow skip over these trailing Unlock calls
(e.g. with early returns).
We also have a second `GetDisasmToUse` method now that takes an already constructed access scope to
prevent deadlocks when we call this from other methods.
Reviewers: #lldb, davide, vsk
Reviewed By: #lldb, davide, vsk
Subscribers: davide, vsk, lldb-commits
Differential Revision: https://reviews.llvm.org/D51319
llvm-svn: 340835
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Sometimes reading an output *.ll file it is not easy to understand why some callsites are not inlined. We can read output of inline remarks (option --pass-remarks-missed=inline) and try correlating its messages with the callsites.
An easier way proposed by this patch is to add to every callsite processed by Inliner an attribute with the latest message that describes the cause of not inlining this callsite. The attribute is called //inline-remark//. By default this feature is off. It can be switched on by the option //-inline-remark-attribute//.
For example in the provided test the result method //@test1// has two callsites //@bar// and inline remarks report different inlining missed reasons:
remark: <unknown>:0:0: bar not inlined into test1 because too costly to inline (cost=-5, threshold=-6)
remark: <unknown>:0:0: bar not inlined into test1 because it should never be inlined (cost=never): recursive
It is not clear which remark correspond to which callsite. With the inline remark attribute enabled we get the reasons attached to their callsites:
define void @test1() {
call void @bar(i1 true) #0
call void @bar(i1 false) #2
ret void
}
attributes #0 = { "inline-remark"="(cost=-5, threshold=-6)" }
..
attributes #2 = { "inline-remark"="(cost=never): recursive" }
Patch by: yrouban (Yevgeny Rouban)
Reviewers: xbolva00, tejohnson, apilipenko
Reviewed By: xbolva00, tejohnson
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D50435
llvm-svn: 340834
|
|
|
|
|
|
| |
Some of the test cases contained the same load twice instead of a different load.
llvm-svn: 340833
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Relanding r340564, original commit message:
Fixes the handling of *_DS relocations used on DQ-form instructions where we
were overwriting some of the extended opcode bits. Also adds an alignment check
so that the user will receive a diagnostic error if the value we are writing
is not properly aligned.
Differential Revision: https://reviews.llvm.org/D51124
llvm-svn: 340832
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adding support for a16 for gfx9. A16 bit replaces r128 bit for gfx9.
Change-Id: Ie8b881e4e6d2f023fb5e0150420893513e5f4841
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50575
llvm-svn: 340831
|
|
|
|
|
|
|
|
|
| |
default invalid buffer descriptor. NFCI
Also change the default buffer size for UsedBuffer entries to -1 (i.e. "unknown
size"). No functional change intended.
llvm-svn: 340830
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dex is now mature enough to be used as the default static index. This
patch performs the switch but introduces a hidden flag to allow users
fallback to Mem in case something happens.
Reviewed by: ioeric
Differential Revision: https://reviews.llvm.org/D51352
llvm-svn: 340828
|
|
|
|
|
|
|
|
| |
This is cleanup after newly introduced google/benchmark library
(rL340809). Many buildbots fail to identify regex engine support, so
this should presumably fix the issue.
llvm-svn: 340827
|
|
|
|
| |
llvm-svn: 340826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the 'wait-times' table.
This patch also uses colors to highlight problematic wait-time entries.
A problematic entry is an entry with an high wait time that tends to match (or
exceed) the size of the scheduler's buffer.
Color RED is used if an instruction had to wait an average number of cycles
which is bigger than (or equal to) the size of the underlying scheduler's
buffer.
Color YELLOW is used if the time (in cycles) spend waiting for the
operands or pipeline resources is bigger than half the size of the underlying
scheduler's buffer.
Color MAGENTA is used if an instruction does not consume buffer resources
according to the scheduling model.
llvm-svn: 340825
|
|
|
|
|
|
|
|
|
|
|
| |
ImmutableList used to require elements to have a copy constructor for no
good reason, this patch aims to fix this.
It also required but did not enforce its elements to be trivially
destructible, so a new static_assert is added to guard against misuse.
Differential Revision: https://reviews.llvm.org/D49985
llvm-svn: 340824
|
|
|
|
|
|
| |
drive-by, make the same change in raw_storage_iterator (twice).
llvm-svn: 340823
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Unbuffered stream can cause significant (non-deterministic) latency for the logger.
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51349
llvm-svn: 340822
|
|
|
|
|
|
| |
about reserved/released buffer resources. NFC
llvm-svn: 340821
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes PR31105.
There is code trying to delete dead code that does so by e.g. checking if
the single predecessor of a block is the block itself.
That check fails on a block like this
bb:
br i1 undef, label %bb, label %bb
since that has two (identical) predecessors.
However, after the check for dead blocks there is a call to
ConstantFoldTerminator on the basic block, and that call simplifies the
block to
bb:
br label %bb
Therefore we now do the call to ConstantFoldTerminator before the check if
the block is dead, so it can realize that it really is.
The original behavior lead to the block not being removed, but it was
simplified as above, and then we did a call to
Dest->replaceAllUsesWith(&*I);
with old and new being equal, and an assertion triggered.
Reviewers: chandlerc, fhahn
Reviewed By: fhahn
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D51280
llvm-svn: 340820
|
|
|
|
|
|
| |
Requested in post-commit review for rL339670
llvm-svn: 340819
|
|
|
|
|
|
|
|
|
|
| |
Fix for the out-of-memory error when compiling SemaChecking.cpp
with GVNHoist and ubsan enabled. I've used a cache for inserted
CHIs to avoid excessive memory usage.
Differential Revision: https://reviews.llvm.org/D50323
llvm-svn: 340818
|
|
|
|
| |
llvm-svn: 340817
|
|
|
|
| |
llvm-svn: 340816
|
|
|
|
| |
llvm-svn: 340815
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change removes further cases where the profiling mode
implementation relied on dynamic memory allocation. We're using
thread-local aligned (uninitialized) memory instead, which we initialize
appropriately with placement new.
Addresses llvm.org/PR38577.
Reviewers: eizan, kpw
Subscribers: jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D51278
llvm-svn: 340814
|