Summary:
This patch could be treated as a rebase of D33960. It also fixes PR35547.
A fix for `llvm/test/Other/close-stderr.ll` is proposed in D68164. Seems
the consensus is that the test is passing by chance and I'm not
sure how important it is for us. So it is removed like in D33960 for now.
The rest of the test fixes are just adding `--crash` flag to `not` tool.
** The reason it fixes PR35547 is
`exit` does cleanup including calling class destructor whereas `abort`
does not do any cleanup. In multithreading environment such as ThinLTO or JIT,
threads may share states which mostly are ManagedStatic<>. If faulting thread
tearing down a class when another thread is using it, there are chances of
memory corruption. This is bad 1. It will stop error reporting like pretty
stack printer; 2. The memory corruption is distracting and nondeterministic in
terms of error message, and corruption type (depending one the timing, it
could be double free, heap free after use, etc.).
Reviewers: rnk, chandlerc, zturner, sepavloff, MaskRay, espindola
Reviewed By: rnk, MaskRay
Subscribers: wuzish, jholewinski, qcolombet, dschuff, jyknight, emaste, sdardis, nemanjai, jvesely, nhaehnle, sbc100, arichardson, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, lenary, s.egerton, pzheng, cfe-commits, MaskRay, filcab, davide, MatzeB, mehdi_amini, hiraditya, steven_wu, dexonsmith, rupprecht, seiya, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D67847
Append this to the existing target-features attribute on the function.
Some flags ignore existing attributes, and some overwrite them. Move
towards consistently respecting existing attributes if present. Since
target features act as a state machine on their own, append to the
function attribute. The backend default added feature list, function
attributes, and -mattr will all be appended together, and the later
features can individually toggle the earlier settings.
Summary:
This is the first in a series of patches to enable LLDB debugging of
WebAssembly targets.
Current versions of Clang emit (partial) DWARF debug information in WebAssembly
modules and we can leverage this debug information to give LLDB the ability to
do source-level debugging of Wasm code that runs in a WebAssembly engine.
A way to do this could be to use the remote debugging functionalities provided
by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not
only to connect a debugger to a process running on a remote machine, but also to
connect the debugger to a managed VM or script engine that runs locally,
provided that the engine implements a GDB-remote stub that offers the ability to
access the engine runtime internal state.
To make this work, the GDB-remote protocol would need to be extended with a few
Wasm-specific custom query commands, used to access aspects of the Wasm engine
state (like the Wasm memory, Wasm local and global variables, and so on).
Furthermore, the DWARF format would need to be enriched with a few Wasm-specific
extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf.
This CL introduce classes **ObjectFileWasm**, a file plugin to represent a Wasm
module loaded in a debuggee process. It knows how to parse Wasm modules and
store the Code section and the DWARF-specific sections.
Reviewers: jasonmolenda, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71575
expanded by the deduced pack.
We recently started also deducing the arity of separately-expanded packs
that are merely mentioned within the pack in question, which is
incorrect.
Instead of passing all the arguments for dotest.py as a single CMake
variable, lit now uses separate variables for the different test
binaries. Before this change they'd all get patched as part of the
LLDB_DOTEST_ARGS. We need to patch the new variables as well.
Instead of passing all the arguments for dotest.py as a single CMake
variable, lldb-dotest now uses separate variables for the different test
binaries. Before this change they'd all get patched as part of the
LLDB_DOTEST_ARGS. We need to patch the new variables as well.
When tail duplication estimates a size of tail it uses instruction
count. Account for a number of instrictions in a bundle too.
Differential Revision: https://reviews.llvm.org/D72783
If current kind of the translation unit is TU_Prefix and it is not
complete, cannot decide what to do with virtual members/table at that
time, need to delay it to later stages.
After extracting, fix up debug info in both the old and new functions by
1) Pointing line locations and debug intrinsics to the new subprogram
scope, and
2) Deleting intrinsics which point to values outside of the new
function.
Depends on https://reviews.llvm.org/D72795.
Testing: check-llvm, check-clang, a build of LNT in the `-Os -g` config
with "-mllvm -hot-cold-split=1" set, and end-to-end debugging of a toy
program which undergoes splitting to verify that lldb can find
variables, single step, etc. in extracted code.
rdar://45507940
Differential Revision: https://reviews.llvm.org/D72801
This does produce slightly different code. Now a unique IMPLICIT_DEF
is emitted for each of the implicit_def operands, rather than reusing
the same one.
I'm mildly worried about potentially reordering exp/exp_done with
IntrWriteMem on the intrinsic.
Requires hacking out the illegal type on SI, so manually select that
case during lowering.
This now develops the same problem G_ZEXT/G_ANYEXT have where the
requested type is assumed to be the source type. This will be fixed
separately by creating intermediate merges.
Summary:
In July 21 2010 `llvm::NamedMDNode` was refactored such that it would no
longer subclass `llvm::Value`:
https://github.com/llvm/llvm-project/commit/2637cc1a38d7336ea30caf
As part of this change, a map type from metadata names to their named
metadata, `llvm::MDSymbolTable`, was deleted. In its place, the type
of member `llvm::Module::NamedMDSymTab` was changed, from
`llvm::MDSymbolTable` to `void *`. The underlying memory allocations
for this pointer were changed to `new StringMap<NamedMDNode *>()`.
However, as far as I can tell, there's no need for obscuring the
underlying type being pointed to by the `void *`, and no need for
static casts from `void *` to `StringMap`. In fact, I don't think
there's a need for explicit calls to `new` and `delete` at all.
This commit changes `NamedMDSymTab` from a pointer to a reference, which
automatically couples its lifetime with the lifetime of its owning
`llvm::Module` instance, thus removing the explicit calls to `new` and
`delete` in the `llvm::Module` constructor and destructor. It also
changes the type from `void *` to a newly defined `NamedMDSymTabType`,
and removes the static casts.
Test Plan:
An ASAN-enabled build and run of `check-all` succeeds with this change
(aside from some tests that always fail for me in ASAN for some reason,
such as `check-clang` `SemaTemplate/stack-exhaustion.cpp`).
Reviewers: aprantl, dblaikie, chandlerc, pcc, echristo
Reviewed By: dblaikie
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72812
Instead of passing all the arguments for dotest.py as a single CMake
variable, lldb-dotest now uses separate variables for the different test
binaries. Before this change they'd all get patched as part of the
LLDB_DOTEST_ARGS. We need to patch the new variables as well.
The C11 API specifies that to initialize a recursive mutex,
mtx_plain | mtx_recursive should be used with mtx_init.
Differential Revision: https://reviews.llvm.org/D72809
It appears to be rather useful when analyzing Loops with multiple
deoptimizing exits, perhaps merged ones.
For now it is used in LoopPredication, will be adding more uses
in other loop passes.
Reviewers: asbirlea, fhahn, skatkov, spatel, reames
Reviewed By: reames
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72754
The GCC build failures have been addressed, and the LLDB failures were
fixed by LLDB.
I have also verified that the apple-clang 9.0 segfault no longer
occurs.
Original Message:
The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can cause ABI
breakages, including introducing new symbols.
This patch aims to:
(1) Make clear which functions are explicitly instatiated.
(2) Prevent new functions from being accidentally instantiated.
(3) Allow a migration path for adding or removing functions from the
explicit instantiation over time.
Although this new formulation is uglier, it is preferable from a
maintainability and readability standpoint because it explicitly
enumerates the functions we've chosen to expose in our ABI. Changing
this list is non-trivial and requires thought and planning.
(3) is achieved by making it possible to control the extern template declaration
separately from it's definition. Meaning we could add a new definition to
the dylib, wait for it to roll out, then add the extern template
declaration to the header. Similarly, we could remove existing extern
template declarations while still keeping the definition to prevent ABI
breakages.
This patch is needed in order to work around a GCC bug that fails to
explicitly instantiate a non-template function of a class template when
there is another overload that's a function template.
(See https://godbolt.org/z/4bUQ_b)
This patch SFINAE's away the function templates when the argument is
a basic_string.
Summary:
InlineResult is used both in APIs assessing whether a call site is
inlinable (e.g. llvm::isInlineViable) as well as in the function
inlining utility (llvm::InlineFunction). It means slightly different
things (can/should inlining happen, vs did it happen), and the
implicit casting may introduce ambiguity (casting from 'false' in
InlineFunction will default a message about hight costs,
which is incorrect here).
The change renames the type to a more generic name, and disables
implicit constructors.
Reviewers: eraman, davidxl
Reviewed By: davidxl
Subscribers: kerbowa, arsenm, jvesely, nhaehnle, eraman, hiraditya, haicheng, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72744
Summary:
* Add shaped container type interface which allows infering the shape, element
type and attribute of shaped container type separately. Show usage by way of
tensor type inference trait which combines the shape & element type in
infering a tensor type;
- All components need not be specified;
- Attribute is added to allow for layout attribute that was previously
discussed;
* Expand the test driver to make it easier to test new creation instances
(adding new operands or ops with attributes or regions would trigger build
functions/type inference methods);
- The verification part will be moved out of the test and to verify method
instead of ops implementing the type inference interface in a follow up;
* Add MLIRContext as arg to possible to create type for ops without arguments,
region or location;
* Also move out the section in OpDefinitions doc to separate ShapeInference doc
where the shape function requirements can be captured;
- Part of this would move to the shape dialect and/or shape dialect ops be
included as subsection of this doc;
* Update ODS's variable usage to match camelBack format for builder,
state and arg variables;
- I could have split this out, but I had to make some changes around
these and the inconsistency bugged me :)
Differential Revision: https://reviews.llvm.org/D72432
Summary: Duplicate code in widenWithVariantLoadUseCodegen is removed and also use assert to check unknown extension type as it should be filtered out by the pre condition check before calling this function.
Reviewers: az, sanjoy, sebpop, efriedma, javed.absar, sanjoy.google
Reviewed By: efriedma
Subscribers: hiraditya, llvm-commits, amehsan
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72652
Factor out the logic needed to update debug locations contained within
MD_loop metadata.
This refactor is preparation for a future change that also needs to
rewrite MD_loop metadata.
rdar://45507940
This reverts D53469, which changed llvm's DWARF emission to emit
DW_AT_call_return_pc as a function-local offset. Such an encoding is not
compatible with post-link block re-ordering tools and isn't standards-
compliant.
In addition to reverting back to the original DW_AT_call_return_pc
encoding, teach lldb how to fix up DW_AT_call_return_pc when the address
comes from an object file pointed-to by a debug map. While doing this I
noticed that lldb's support for tail calls that cross a DSO/object file
boundary wasn't covered, so I added tests for that. This latter case
exercises the newly added return PC fixup.
The dsymutil changes in this patch were originally included in D49887:
the associated test should be sufficient to test DW_AT_call_return_pc
encoding purely on the llvm side.
Differential Revision: https://reviews.llvm.org/D72489
This updates the discussion of lazy reexports, fixes a TBD for a usage example,
and adds a reference to the fully worked lazy reexports example that was added
in e9e26c01cd.
I believe the generated code here can suffer from double rounding.
So I wanted to capture the existing codegen so we can make
decisions about how to fix it.
Based on Don Hinton's patch in https://reviews.llvm.org/D72406. This feature
was accidentally left out of e9e26c01cd, and
would have pessimized concurrent compilation in the default case.
Thanks for spotting this Don!
Ran `git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py format`.
The motivation is to reformat them with trunk gn again right after.
Trunk gn changed formatting of some single-element lists.
Flags are clang's default UI is flags.
We can have an env var in addition to that, but in D69825 nobody has yet
mentioned why this needs an env var, so omit it for now. If someone
needs to set the flag via env var, the existing CCC_OVERRIDE_OPTIONS
mechanism works for it (set CCC_OVERRIDE_OPTIONS=+-fno-integrated-cc1
for example).
Also mention the cc1-in-process change in the release notes.
Also spruce up the test a bit so it actually tests something :)
Differential Revision: https://reviews.llvm.org/D72769
Vedant Kumar