SuccessChanges

Summary

  1. DWARFDebugLoclists: Move to a incremental parsing model (details)
  2. [libTooling] Simplify type structure of `Stencil`s. (details)
  3. [libomptarget] Revert all improvements to support (details)
Commit e1f8c8a16f441aed3aaa6262f932854b74e4f97c by pavel
DWARFDebugLoclists: Move to a incremental parsing model
Summary: This patch stems from the discussion D68270 (including some
offline talks). The idea is to provide an "incremental" api for parsing
location lists, which will avoid caching or materializing parsed data.
An additional goal is to provide a high level location list api, which
abstracts the differences between different encoding schemes, and can be
used by users which don't care about those (such as LLDB).
This patch implements the first part. It implements a call-back based
"visitLocationList" api. This function parses a single location list,
calling a user-specified callback for each entry. This is going to be
the base api, which other location list functions (right now, just the
dumping code) are going to be based on.
Future patches will do something similar for the v4 location lists, and
add a mechanism to translate raw entries into concrete address ranges.
Reviewers: dblaikie, probinson, JDevlieghere, aprantl, SouraVX
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69672
The file was modifiedllvm/test/DebugInfo/X86/dwarfdump-debug-loclists.test
The file was modifiedllvm/test/CodeGen/X86/debug-loclists.ll
The file was modifiedllvm/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp
The file was modifiedllvm/test/tools/llvm-dwarfdump/X86/debug_loclists_startx_length.s
The file was modifiedllvm/lib/DebugInfo/DWARF/DWARFDie.cpp
The file was modifiedllvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
The file was modifiedllvm/lib/DebugInfo/DWARF/DWARFContext.cpp
The file was modifiedllvm/test/DebugInfo/X86/dwarfdump-debug-loclists-error-cases2.s
The file was modifiedllvm/include/llvm/DebugInfo/DWARF/DWARFDebugLoc.h
The file was modifiedllvm/test/DebugInfo/X86/fission-ranges.ll
The file was modifiedllvm/test/DebugInfo/X86/stack-value-piece.ll
Commit ce2b5cb6decb5cce32adde0d23bdea521da0908b by yitzhakm
[libTooling] Simplify type structure of `Stencil`s.
Summary: Currently, stencils are defined as a sequence of
`StencilParts`. This differentiation adds an unneeded layer of
complexity to the definition of Stencils. This change significantly
simplifies the type structure: a stencil is now conceptually any object
implementing `StencilInterface` and `Stencil` is just a thin wrapper for
pointers to this interface.
To account for the sequencing that was supported by the old `Stencil`
type, we introduce a sequencing class that implements
`StencilInterface`. That is, sequences are just another kind of Stencil
and no longer have any special status.
Corresponding to this change in the type structure, we change the way
`cat` is used (and defined). `cat` bundles multiple features: it builds
a stencil from a sequence of subcomponents and admits multiple different
types for its arguments, while coercing them into the right type.
Previously, `cat` was also used to coerce a single `StencilPart` into a
`Stencil`. With that distinction gone, many uses of `cat` (e.g. in the
tests) are unnecessary and have, therefore, been removed.
Reviewers: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69613
The file was modifiedclang/include/clang/Tooling/Transformer/Stencil.h
The file was modifiedclang/unittests/Tooling/StencilTest.cpp
The file was modifiedclang/lib/Tooling/Transformer/Stencil.cpp
Commit 7cea0cea77d15b70d54083ec7c17ae5d49b3f53f by jonathanchesterfield
[libomptarget] Revert all improvements to support
Summary:
[libomptarget] Revert all improvements to support
The change to unity build for nvcc has broken the build for some
developers. This patch reverts to a known-working state.
There has been some confusion over exactly how the build broke. I think
we have reached a common understanding that the disappearing symbols are
from the bitcode library built by clang. The static archive built by
nvcc may show the same problem. Some of the confusion arose from
building the deviceRTL twice and using one or the other library based on
various environmental factors.
I'm pretty sure the problem is clang expanding `__forceinline__` into
both `__inline__` and `attribute(("always_inline"))`. The `__inline__`
attribute resolves to linkonce_odr which is not safe for exporting
symbols from translation units.
"always_inline" is the desired semantic for small functions defined in
one translation unit that are intended to be inlined at link time.
"inline" is not.
This therefore reintroduces the dependency hazard of supporti.h and some
code duplication, and blocks progress separating deviceRTL into reusable
components.
See also D69857, D69859 for attempts at a fix instead of a revert.
Reviewers: ABataev, jdoerfert, grokos, ikitayama, tianshilei1992
Reviewed By: ABataev
Subscribers: mgorny, jfb, openmp-commits
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D69885
The file was modifiedopenmp/libomptarget/deviceRTLs/nvptx/CMakeLists.txt
The file was removedopenmp/libomptarget/deviceRTLs/nvptx/unity.cu
The file was modifiedopenmp/libomptarget/deviceRTLs/nvptx/src/support.h
The file was modifiedopenmp/libomptarget/deviceRTLs/nvptx/src/omptarget-nvptx.h
The file was removedopenmp/libomptarget/deviceRTLs/nvptx/src/support.cu
The file was modifiedopenmp/libomptarget/deviceRTLs/nvptx/src/data_sharing.cu
The file was modifiedopenmp/libomptarget/deviceRTLs/nvptx/src/target_impl.h
The file was modifiedopenmp/libomptarget/deviceRTLs/nvptx/src/debug.h
The file was modifiedopenmp/libomptarget/deviceRTLs/nvptx/src/libcall.cu
The file was addedopenmp/libomptarget/deviceRTLs/nvptx/src/supporti.h