| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 374582
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rdar://problem/55715134
Reviewers: dsanders, bogner, rtereshin
Reviewed By: dsanders
Subscribers: hiraditya, jkorous, dexonsmith, ributzka, cfe-commits, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68252
llvm-svn: 374581
|
|
|
|
|
|
| |
__is_*_assignable(volatile T&, U).
llvm-svn: 374580
|
|
|
|
| |
llvm-svn: 374579
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mgorny
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68878
llvm-svn: 374577
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
|
|
|
|
| |
llvm-svn: 374575
|
|
|
|
|
|
| |
Same as with the import-std-module/sysroot test before.
llvm-svn: 374574
|
|
|
|
|
|
|
|
|
|
| |
The clang IFS ASTConsumer was asserting on enums, records (struct definitions in
C), and typedefs. All it needs to do is skip them because the stub just needs to
expose global object instances and functions.
Differential Revision: https://reviews.llvm.org/D68859
llvm-svn: 374573
|
|
|
|
|
|
|
|
| |
We essentially test libc++ in a sysroot here so let's make sure
that we actually only run this test on platforms where libc++
testing is enabled.
llvm-svn: 374572
|
|
|
|
| |
llvm-svn: 374571
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently when invoking lldb-test symbols -dump-ast it parses all the debug symbols and calls print(...) on the TranslationUnitDecl.
While useful the TranslationUnitDecl::print(...) method gives us a higher level view then the dump from ASTDumper which is what we get when we invoke dump() on a specific AST node.
The main motivation for this change is allow us to verify that the AST nodes we create when we parse DWARF. For example in order to verify we are correctly using DIFlagExportSymbols added by D66667
Differential Revision: https://reviews.llvm.org/D67994
llvm-svn: 374570
|
|
|
|
|
|
|
|
|
| |
__builtin_assume_aligned takes a size_t which is a 32 bit int on
hexagon. Thus, the constant gets converted to a 32 bit value, resulting
in 0 not being a power of 2. This patch changes the constant being
passed to 2**30 so that it fails, but doesnt exceed 30 bits.
llvm-svn: 374569
|
|
|
|
|
|
| |
These are copied from existing test files in x86/PPC.
llvm-svn: 374568
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Implements the following arithmetic intrinsics:
- int_aarch64_sve_sdot
- int_aarch64_sve_sdot_lane
- int_aarch64_sve_udot
- int_aarch64_sve_udot_lane
This patch includes tests for the Subdivide4Argument type added by D67549
Reviewers: sdesmalen, SjoerdMeijer, greened, rengolin, rovka
Reviewed By: sdesmalen
Subscribers: tschuett, kristof.beyls, rkruppe, psnobl, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D67551
llvm-svn: 374566
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a moveAfter method to VPRecipeBase, which can be used to
move elements after other elements, across VPBasicBlocks, if necessary.
Reviewers: dcaballe, hsaito, rengolin, hfinkel
Reviewed By: dcaballe
Differential Revision: https://reviews.llvm.org/D46825
llvm-svn: 374565
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The AIX system assembler does not understand .zero, so we should prefer
emitting .space.
Subscribers: nemanjai, hiraditya, kbarton, MaskRay, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68815
llvm-svn: 374564
|
|
|
|
|
|
|
|
|
|
| |
The behavior from the original patch has changed, since we're no longer
allowing LLVM to just ignore the alignment. Instead, we're just
assuming the maximum possible alignment.
Differential Revision: https://reviews.llvm.org/D68824
llvm-svn: 374562
|
|
|
|
|
|
|
|
|
|
|
|
| |
ds_[read/write]_addtid_b32
See https://bugs.llvm.org/show_bug.cgi?id=37941
Reviewers: arsenm, rampitec
Differential Revision: https://reviews.llvm.org/D68787
llvm-svn: 374561
|
|
|
|
| |
llvm-svn: 374560
|
|
|
|
|
|
|
|
|
|
|
|
| |
buffer_atomic_[fcmpswap/fmin/fmax]*
See https://bugs.llvm.org/show_bug.cgi?id=28232
Reviewers: arsenm, rampitec
Differential Revision: https://reviews.llvm.org/D68788
llvm-svn: 374559
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Move the `RewriteRule` class and related declarations into its own set
of files (header, implementation). Only the `Transformer` class is left in the
Transformer-named files. This change clarifies the distinction between the
`RewriteRule` class, which is essential to the Transformer library, and the
`Transformer` class, which is only one possible `RewriteRule` interpreter
(compare to `TransformerClangTidyCheck`, a clang-tidy based interpreter).
Reviewers: gribozavr
Subscribers: jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68795
llvm-svn: 374558
|
|
|
|
|
|
|
|
|
|
| |
See https://bugs.llvm.org/show_bug.cgi?id=43524
Reviewers: arsenm, rampitec
Differential Revision: https://reviews.llvm.org/D68785
llvm-svn: 374557
|
|
|
|
|
|
|
|
|
| |
Support linking OCaml modules against LLVM dylib when requested,
rather than against static libs that might not be installed at all.
Differential Revision: https://reviews.llvm.org/D68452
llvm-svn: 374556
|
|
|
|
|
|
|
|
|
|
| |
The diffs suggest that we are missing some more basic
analysis/transforms, but this keeps the vector path in
sync with the scalar (rL374397). This is again a
preliminary step for introducing the reverse transform
in IR as proposed in D63382.
llvm-svn: 374555
|
|
|
|
| |
llvm-svn: 374554
|
|
|
|
|
|
|
|
|
|
| |
See https://bugs.llvm.org/show_bug.cgi?id=43486
Reviewers: artem.tamazov, arsenm
Differential Revision: https://reviews.llvm.org/D68350
llvm-svn: 374553
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Removes the `isEqual` method from StencilPartInterface and modifies equality to
use the string representation returned by the `toString` method for comparison.
This means the `run` and `selection` stencils return true by default, and
clients should be cautious in relying on equality operator for comparison of
stencils containing parts generated by these functions.
It also means we no longer need the custom RTTI support (typeId() and
down_cast()), so it has been removed.
Patch by Harshal T. Lehri.
Reviewers: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68825
llvm-svn: 374552
|
|
|
|
| |
llvm-svn: 374551
|
|
|
|
|
|
| |
Renamed a file that I missed in r374540.
llvm-svn: 374549
|
|
|
|
| |
llvm-svn: 374548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The command `od -t x` is used to dump data in hex format.
The LIT tests assumes that the hex characters are in lowercase.
However, there are also platforms which use uppercase letter.
To solve this issue the tests are updated to use the new
`--ignore-case` option of FileCheck.
Reviewers: Bigcheese, jakehehrlich, rupprecht, espindola, alexshap, jhenderson
Differential Revision: https://reviews.llvm.org/D68693
llvm-svn: 374547
|
|
|
|
| |
llvm-svn: 374545
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a "double" (64-bit) value has zero low 32-bits, it's possible to load
such value into a GP/FP registers as an instruction immediate. But now
assembler loads only high 32-bits of the value.
For example, if a target register is GPR the `li.d $4, 1.0` instruction
converts into the `lui $4, 16368` one. As a result, we get `0x3FF00000`
in the register. While a correct representation of the `1.0` value is
`0x3FF0000000000000`. The patch fixes that.
Differential Revision: https://reviews.llvm.org/D68776
llvm-svn: 374544
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compatible with MSVC
MS name mangling supports cache for first 10 distinct function
arguments. The error was when non cached template type occurred twice
(e.g. 11th and 12th). For such case in code there is another cache
table TemplateArgStrings (for performance reasons). Then one '@'
character at the end of the mangled name taken from this table was
missing. For other cases the missing '@' character was added in
the call to mangleSourceName(TemplateMangling) in the cache miss code,
but the cache hit code didn't add it.
This fixes a regression from r362560.
Patch by Adam Folwarczny <adamf88@gmail.com>!
Differential Revision: https://reviews.llvm.org/D68099
llvm-svn: 374543
|
|
|
|
|
|
| |
https://reviews.llvm.org/D68704 changed the output format.
llvm-svn: 374542
|
|
|
|
|
|
|
|
|
|
|
| |
This removes a few fields that are not useful:
"Section Name", "Address", "Offset" and "Link"
(they duplicated the information available under
the "Sections [" tag).
Differential revision: https://reviews.llvm.org/D68704
llvm-svn: 374541
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change moves tests for checkers and infrastructure into separate
directories, making it easier to find infrastructure tests. Tests for
checkers are already easy to find because they are named after the
checker. Tests for infrastructure were difficult to find because they
were outnumbered by tests for checkers. Now they are in a separate
directory.
Reviewers: jfb, jdoerfert, lebedev.ri
Subscribers: srhines, nemanjai, aheejin, kbarton, christof, mgrang, arphaman, jfb, lebedev.ri, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68807
llvm-svn: 374540
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 374539
|
|
|
|
|
|
|
|
|
|
|
|
| |
The FileCheck utility is enhanced to support a `--ignore-case`
option. This is useful in cases where the output of Unix tools
differs in case (e.g. case not specified by Posix).
Reviewers: Bigcheese, jakehehrlich, rupprecht, espindola, alexshap, jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D68146
llvm-svn: 374538
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arguments for windows
This should allow lldb-server to operate on files with non-ascii
pathnames.
I tried looking around in lldb/tools, and this seemed like the only
other tool (other than the main lldb driver itself) that would be
used (implicitly) by an end user (which could be working in
non-ascii paths).
Differential Revision: https://reviews.llvm.org/D68864
llvm-svn: 374537
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently -verify-scev only fails if there is a constant difference
between two BE counts. This misses a lot of cases.
This patch adds a -verify-scev-strict options, which fails for any
non-zero differences, if used together with -verify-scev.
With the stricter checking, some unit tests fail because
of mis-matches, especially around IndVarSimplify.
If there is no reason I am missing for just checking constant deltas, I
am planning on looking into the various failures.
Reviewers: efriedma, sanjoy.google, reames, atrick
Reviewed By: sanjoy.google
Differential Revision: https://reviews.llvm.org/D68592
llvm-svn: 374535
|
|
|
|
|
|
| |
Now that its used by isNegatibleForFree we should try to avoid costly deep recursion
llvm-svn: 374534
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68780
llvm-svn: 374533
|
|
|
|
| |
llvm-svn: 374532
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
was requested, take 2
Summary:
The previous attempt at making nameless process not match when searching for a
given name failed because the macos implementation was depending on this detail
in its partial matching strategy. Doing partial matching to avoid expensive
lookups is a perfectly valid thing to do, the way it was implemented seems
somewhat unexpected.
This patch implements it differently by providing special
methods in the ProcessInstanceInfoMatch which match only a subset of fields,
and changes mac host code to use those instead.
Then, it re-applies r373925 to get make the ProcessInstanceInfoMatch with a
name *not* match a nameless process.
Reviewers: JDevlieghere, teemperor, jingham
Subscribers: wallace, lldb-commits
Differential Revision: https://reviews.llvm.org/D68631
llvm-svn: 374529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we insert them from function pass some analysis may be missing or invalid.
Fixes PR42877.
Reviewers: eugenis, leonardchan
Reviewed By: leonardchan
Subscribers: hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D68832
> llvm-svn: 374481
Signed-off-by: Vitaly Buka <vitalybuka@google.com>
llvm-svn: 374527
|
|
|
|
|
|
|
|
|
| |
This avoids the currently MSVC specific codepath of using the
wchar entry point and converting that to utf8.
Differential Revision: https://reviews.llvm.org/D68770
llvm-svn: 374526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently don't handle the error in the Expected we get
when searching for an equal local DeclContext. Usually this can't
happen as this would require that we have a STL container and
we can find libc++'s std module, but when we load the module in
the expression parser the module doesn't even contain the 'std'
namespace. The only way I see to test this is by having a fake
'std' module that requires a special define to actually provide
its contents, while it will just be empty (that is, it doesn't
even contain the 'std' namespace) without that define. LLDB currently
doesn't know about that define in the expression parser, so it
will load the wrong 'empty' module which should trigger this error.
Also removed the 'auto' for that variable as the function name
doesn't make it obvious that this is an expected and not just
a optional/ptr (which is how this slipped in from the start).
llvm-svn: 374525
|