| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 358008
|
| |
|
|
| |
llvm-svn: 358007
|
| |
|
|
| |
llvm-svn: 358006
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
// 0 - (X sdiv C) -> (X sdiv -C) provided the negation doesn't overflow.
This fold has been around for many years and nobody noticed the potential
vector miscompile from overflow until recently...
So it seems unlikely that there's much demand for a vector sdiv optimization
on arbitrary vector constants, so just limit the matching to splat constants
to avoid the possible bug.
Differential Revision: https://reviews.llvm.org/D60426
llvm-svn: 358005
|
| |
|
|
| |
llvm-svn: 358004
|
| |
|
|
| |
llvm-svn: 358003
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current llvm/clang et al. project can be built with the latest developer toolset (devtoolset-8) on RHEL, which provides GCC 8.2.1.
However, the result compiler will not identify this toolset itself when compiling programs, which is of course not desirable.
After the patch - which simply adds the name of the developer toolset to the existing list - it gets identified and selected, as shown below:
[bamboo@bamboo llvm-project]$ clang -v
clang version 9.0.0 (https://github.com/llvm/llvm-project.git e5ac385fb1ffa4bd3875ea6a4d24efdbd7814572)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/bamboo/llvm/bin
Found candidate GCC installation: /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1
Found candidate GCC installation: /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7
Found candidate GCC installation: /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation: /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
Patch By: Radu-Adrian Popescu
Reviewers: tstellar, fedor.sergeev
Reviewed By: tstellar
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59987
llvm-svn: 358002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vector counterparts
This patch factors out mappings of scalar maths functions to their vector
counterparts from TargetLibraryInfo.cpp to a separate VecFuncs.def file. Such
mappings are currently available for Accelerate framework, and SVML library.
This is in support of the follow-up: https://reviews.llvm.org/D59881
Patch by pjeeva01
Differential revision: https://reviews.llvm.org/D60211
llvm-svn: 358001
|
| |
|
|
| |
llvm-svn: 358000
|
| |
|
|
|
|
| |
An older version of this could return false but now that this always succeeds we can just inline and simplify it.
llvm-svn: 357999
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Use optimized hashing while writing time trace by join two hashes to one.
Used for -ftime-trace option.
Reviewers: rnk, takuto.ikuta
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60404
llvm-svn: 357998
|
| |
|
|
| |
llvm-svn: 357997
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously the tests in lld for RISC-V were given in yaml format as
LLVM's RISC-V assembler support was incomplete. Now that the
assembler/disassembler has matured we can rewrite all tests to use
LLVM's tools.
Differential Revision: https://reviews.llvm.org/D60415
llvm-svn: 357996
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code previously specified a 32-bit range for R_RISCV_HI20 and
R_RISCV_LO12_[IS], however this is incorrect as the maximum offset on
RV64 that can be formed from the immediate of lui and the displacement
of an I-type or S-type instruction is -0x80000800 to 0x7ffff7ff. There
is also the same issue with a c.lui and LO12 pair, whose actual
addressable range should be -0x20800 to 0x1f7ff.
The tests will be included in the next patch that converts all RISC-V
tests to use llvm-mc instead of yaml2obj, as assembler support has
matured enough to write tests in them.
Differential Revision: https://reviews.llvm.org/D60414
llvm-svn: 357995
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
number of files.
Summary:
At Mozilla we are using this tool in order to perform review-time static-analysis, since some patches contain a large number of files we've discovered this issue, where `stderr` gets mixed with `stdout` thus obfuscating our possibility to parse the output.
The patch that we are currently use can be found [here](https://searchfox.org/mozilla-central/source/build/build-clang/clang-tidy-8.patch).
This is just an upstream of the original patch.
Reviewers: JonasToth
Reviewed By: JonasToth
Subscribers: cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D60453
llvm-svn: 357994
|
| |
|
|
|
|
|
| |
There were some errors in the committed test checks, left in due to a git
stash apply mishap.
llvm-svn: 357993
|
| |
|
|
|
|
|
|
| |
handling
When bitcasting from a source op to a larger bitwidth op, split the demanded bits and OR them on top of one another and demand those merged bits in the SimplifyDemandedBits call on the source op.
llvm-svn: 357992
|
| |
|
|
|
|
|
| |
One of the tests in riscv64-lp64-lp64f-lp64d would have had a different
lowering for lp64f/lp64d as a float argument was missed.
llvm-svn: 357991
|
| |
|
|
| |
llvm-svn: 357990
|
| |
|
|
|
|
|
|
|
| |
float patches
Split tests in to files representing the subset of RISC-V ABIs they should
have identical output for.
llvm-svn: 357989
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With MergeValues() removed, amend DebugLocEntry's constructor so that it
takes multiple values rather than a single, and keep non-fragment values
in OpenRanges, as this allows some cleanup of the code in
buildLocationList().
Reviewers: aprantl, dblaikie, loladiro
Reviewed By: aprantl
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D59303
llvm-svn: 357988
|
| |
|
|
| |
llvm-svn: 357987
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure ASTImporter::Import_New(const Decl *) returns
a Expected<const Decl *> and not Expected<Decl *> to
make the clang/unittests/AST/ASTImporterTest.cpp compile
without the warning
clang/unittests/AST/ASTImporterTest.cpp:117:12: error: no viable conversion from 'Expected<clang::Decl *>' to 'Expected<const clang::Decl *>'
return Imported;
(I got the above when building with clang 3.6).
llvm-svn: 357985
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some of these were present in files which should never be read by swig
(and we also had one in the interface file, which is only read by swig).
They are probably leftovers from the time when we were running swig over
lldb headers directly.
While writing this patch, I noticed that some of the #ifdefs were
guarding public functions that were operating on lldb_private data
types. While it wasn't strictly necessary for this patch, I made these
private, as nobody should really be accessing them. This can potentially
break existing code if it happened to use these methods, though it will
only break at build time -- if someone builds against an old header, he
should still be able to link to a new lldb library, since the functions
are still there.
We could keep these public for backward compatbility, but I would argue
that if anyone was actually using these functions for anything, his code
is already broken.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60400
llvm-svn: 357984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the following doxygen warning when building the lldb-cpp-doc
target.
This commit fixes:
SBStructuredData.h:94 warning: Found unknown command `\dst'
SBStructuredData.h:97 warning: Found unknown command `\dst'
SBStructuredData.h:98 warning: Found unknown command `\dst'
SBStructuredData.h:100 warning: Found unknown command `\dst'
SBStructuredData.h:104 warning: Found unknown command `\dst'
Patch by: Konrad Kleine
Differential revision: https://reviews.llvm.org/D60443
llvm-svn: 357983
|
| |
|
|
|
|
|
| |
Because of r357925, this member function doesn't have to be a
template of ELFT.
llvm-svn: 357982
|
| |
|
|
| |
llvm-svn: 357981
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a space missing in some the documentation for
lldb::BreakpointsWriteToFile.
This fixes the following doxygen error when building the lldb-cpp-doc
target:
llvm-project/lldb/include/lldb/API/SBTarget.h:775 warning: Found
unknown command `\btrue'
Patch by: Konrad Kleine
Differential revision: https://reviews.llvm.org/D60442
llvm-svn: 357980
|
| |
|
|
|
|
| |
for mingw
llvm-svn: 357979
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This will make it easier to expand on the documentation in the future
that avoids cluttering the code.
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60398
llvm-svn: 357978
|
| |
|
|
| |
llvm-svn: 357977
|
| |
|
|
|
|
|
|
|
|
|
| |
Standalone builds of projects other than llvm itself (lldb, libcxx,
etc) include HandleLLVMOptions but not the top level llvm CMakeLists,
so we need to set this variable here to ensure that it always has a
value.
This should fix the build issues some folks have been seeing.
llvm-svn: 357976
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds support for parsing STACK CFI records from breakpad
files. The expressions specifying the values of registers are not
parsed.The idea is that these will be handed off to the postfix
expression -> dwarf compiler, once it is extracted from the internals of
the NativePDB plugin.
Reviewers: clayborg, amccarth, markmentovai
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D60268
llvm-svn: 357975
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The MergeValues() function would try to merge two entries if they shared
the same beginning label. Having the same beginning label means that the
former entry's range would be empty; however, after D55919 we no longer
create entries for empty ranges, so we can no longer land in a situation
where that check in MergeValues would succeed. Instead, the "merging" is
done by keeping the live values from the preceding empty ranges in
OpenRanges, and adding them to the first non-empty range.
Reviewers: aprantl, dblaikie, loladiro
Reviewed By: aprantl
Subscribers: llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D59301
llvm-svn: 357974
|
| |
|
|
|
|
| |
There are no instructions VEX or EVEX instructions that set this field.
llvm-svn: 357973
|
| |
|
|
|
|
|
|
|
|
| |
instead of the composite EVEX_LL field. Remove the EVEX_LL field. NFCI
The composite existed to simplify some other tablegen code and not really in an
important way. Remove the combined field and just calculate the vector size
using two ifs.
llvm-svn: 357972
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The instruction's document this as W0 for the VEX encoding. But there's a
footnote mentioning that VEX.W is ignored in 64-bit mode. And the main VEX
encoding description says the VEX.W bit is ignored for instructions that are
equivalent to a legacy SSE instruction that uses REX.W to select a GPR which
would apply here.
By making this match EVEX we can remove a special case of allowing EVEX2VEX to
turn an EVEX.WIG instruction into VEX.W0.
llvm-svn: 357971
|
| |
|
|
|
|
| |
with clear meanings.
llvm-svn: 357970
|
| |
|
|
|
|
|
|
|
| |
Switch part of the computeOverflowForSignedAdd() implementation to
use Range.isAllNegative() rather than KnownBits.isNegative() and
similar. They do the same thing, but using the ConstantRange methods
allows dropping the KnownBits variables more easily in D60420.
llvm-svn: 357969
|
| |
|
|
|
|
| |
Preparation for D60420.
llvm-svn: 357968
|
| |
|
|
| |
llvm-svn: 357967
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D60431
llvm-svn: 357966
|
| |
|
|
| |
llvm-svn: 357965
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm, nhaehnle
Subscribers: kzhuravl, jvesely, wdng, yaxunl, rovka, kristof.beyls, dstuttard, tpr, t-tye, volkan, llvm-commits
Differential Revision: https://reviews.llvm.org/D57166
llvm-svn: 357964
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have occasional crashes coming from SBThread::GetExtendedBacktraceThread. The
symptom is that we got true back from HasThreadScope - so we should have a valid
live thread, but then when we go to use the thread, it is not good anymore and we
crash.
I can't spot any obvious cause for this crash, but in looking for same I noticed
that in the current code we check that the thread is valid, THEN we take the stop
locker. We really should do that in the other order, and ensure that the process
will stay stopped before we check our thread is still good. That's what this patch does.
<rdar://problem/47478205>
llvm-svn: 357963
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D60177
llvm-svn: 357962
|
| |
|
|
|
|
| |
as a start for the monorepo .gitignore.
llvm-svn: 357961
|
| |
|
|
|
|
|
|
|
| |
It's been on in Android for a while without causing problems, so it's time
to make it the default and remove the flag.
Differential Revision: https://reviews.llvm.org/D60355
llvm-svn: 357960
|
| |
|
|
|
|
| |
This changes the operand type from v4f32/v2f64 to iPTR which seems more correct. But that doesn't seem to do anything other than change the comments in X86GenDAGISel.inc. Probably because we use a ComplexPattern to do the matching so there's no autogenerated code to change.
llvm-svn: 357959
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit r357944 and r357949.
These changes failed to account for the fact that
the guard object is under aligned for atomic operations
on 32 bit platforms (It's aligned to 4 bytes but we require 8).
llvm-svn: 357958
|