1. [Polly] Fix build after IRBuilder changes (details)
  2. Reapply "[IRBuilder] Virtualize IRBuilder" (details)
  3. [FPEnv][ARM] Don't call mutateStrictFPToFP when lowering (details)
  4. [lldb/Plugin] Fix plugin definition for ProcessWindows (details)
  5. [Coroutines][1/6] New pass manager: coro-early (details)
  6. GlobalISel: Extend narrowing to G_ASHR (details)
  7. [CMake] CheckAtomic.cmake: catch false positives in RISC-V (details)
  8. AMDGPU/GlobalISel: Custom lower 32-bit G_UDIV/G_UREM (details)
Commit 55cfb1fb501d0f72518062b6655d4a788258c9f7 by nikita.ppv
[Polly] Fix build after IRBuilder changes

Simply dropping the createPollyIRBuilder() function here, because
it doesn't do much. Also directly initialize Expander in
ScopExpander instead of going through the copy-constructor.
The file was modifiedpolly/include/polly/CodeGen/IRBuilder.h (diff)
The file was modifiedpolly/lib/CodeGen/PPCGCodeGeneration.cpp (diff)
The file was modifiedpolly/lib/CodeGen/CodeGeneration.cpp (diff)
The file was modifiedpolly/lib/Support/ScopHelper.cpp (diff)
Commit 3eaa53e80543813a2274391956e91d275950fbf8 by nikita.ppv
Reapply "[IRBuilder] Virtualize IRBuilder"

Relative to the original commit, this fixes some warnings,
and is based on the deletion of the IRBuilder copy constructor
in D74693. The automatic copy constructor would no longer be


Related llvm-dev thread:

This patch moves the IRBuilder from templating over the constant
folder and inserter towards making both of these virtual.
There are a couple of motivations for this:

1. It's not possible to share code between use-sites that use
different IRBuilder folders/inserters (short of templating the code
and moving it into headers).
2. Methods currently defined on IRBuilderBase (which is not templated)
do not use the custom inserter, resulting in subtle bugs (e.g.
incorrect InstCombine worklist management). It would be possible to
move those into the templated IRBuilder, but...
3. The vast majority of the IRBuilder implementation has to live
in the header, because it depends on the template arguments.
4. We have many unnecessary dependencies on IRBuilder.h,
because it is not easy to forward-declare. (Significant parts of
the backend depend on it via TargetLowering.h, for example.)

This patch addresses the issue by making the following changes:

* IRBuilderDefaultInserter::InsertHelper becomes virtual.
  IRBuilderBase accepts a reference to it.
* IRBuilderFolder is introduced as a virtual base class. It is
implemented by ConstantFolder (default), NoFolder and TargetFolder.
  IRBuilderBase has a reference to this as well.
* All the logic is moved from IRBuilder to IRBuilderBase. This means
  that methods can in the future replace their IRBuilder<> & uses
  (or other specific IRBuilder types) with IRBuilderBase & and thus
  be usable with different IRBuilders.
* The IRBuilder class is now a thin wrapper around IRBuilderBase.
  Essentially it only stores the folder and inserter and takes care
  of constructing the base builder.

What this patch doesn't do, but should be simple followups after this change:

* Fixing use of the inserter for creation methods originally defined
  on IRBuilderBase.
* Replacing IRBuilder<> uses in arguments with IRBuilderBase, where useful.
* Moving code from the IRBuilder header to the source file.

From the user perspective, these changes should be mostly transparent:
The only thing that consumers using a custom inserted may need to do is
inherit from IRBuilderDefaultInserter publicly and mark their InsertHelper
as public.

Differential Revision:
The file was modifiedllvm/lib/Transforms/Scalar/SROA.cpp (diff)
The file was modifiedllvm/include/llvm/IR/IRBuilder.h (diff)
The file was modifiedllvm/lib/Analysis/ConstantFolding.cpp (diff)
The file was modifiedllvm/include/llvm/IR/ConstantFolder.h (diff)
The file was modifiedllvm/lib/IR/IRBuilder.cpp (diff)
The file was modifiedpolly/include/polly/CodeGen/IRBuilder.h (diff)
The file was addedllvm/include/llvm/IR/IRBuilderFolder.h
The file was modifiedllvm/include/llvm/IR/NoFolder.h (diff)
The file was modifiedclang/lib/CodeGen/CGBuilder.h (diff)
The file was modifiedllvm/include/llvm/Analysis/TargetFolder.h (diff)
Commit 594a89f7270da74c89f2321432bc6a7135773fa5 by john.brawn
[FPEnv][ARM] Don't call mutateStrictFPToFP when lowering

mutateStrictFPToFP can delete the node and replace it with another with the same
value which can later cause problems, and returning the result of
mutateStrictFPToFP doesn't work because SelectionDAGLegalize expects that the
returned value has the same number of results as the original. Instead handle
things by doing the mutation manually.

Differential Revision:
The file was modifiedllvm/test/CodeGen/ARM/fp-intrinsics.ll (diff)
The file was modifiedllvm/lib/Target/ARM/ARMISelLowering.cpp (diff)
Commit 3431dc32a4162c0c3e0e0cd3e9e550c5f3c57047 by Jonas Devlieghere
[lldb/Plugin] Fix plugin definition for ProcessWindows

This should fix the unresolved external symbol error.
The file was modifiedlldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp (diff)
Commit e9849d5195e9951a8210ebf63d19c014800c3368 by modocache
[Coroutines][1/6] New pass manager: coro-early

The first in a series of patches that ports the LLVM coroutines passes
to the new pass manager infrastructure. This patch implements

NB: All coroutines passes begin by checking that coroutine intrinsics are
declared within the LLVM IR module they're operating on. To do so, they call
`coro::declaresIntrinsics`. The next 3 patches in this series, which add new
pass manager implementations of the 'coro-split', 'coro-elide', and
'coro-cleanup' passes, use a similar pattern as the one used here: a static
function is shared across both old and new passes to detect if relevant
coroutine intrinsics are delcared. To make this pattern easier to read, this
patch adds `const` keywords to the parameters of `coro::declaresIntrinsics`.

Reviewers: GorNishanov, lewissbaker, junparser, chandlerc, deadalnix, wenlei

Reviewed By: wenlei

Subscribers: ychen, wenlei, EricWF, hiraditya, llvm-commits

Tags: #llvm

Differential Revision:
The file was modifiedllvm/lib/Passes/LLVMBuild.txt (diff)
The file was addedllvm/include/llvm/Transforms/Coroutines/CoroEarly.h
The file was modifiedllvm/lib/Passes/PassBuilder.cpp (diff)
The file was modifiedllvm/lib/Passes/PassRegistry.def (diff)
The file was modifiedllvm/lib/Transforms/Coroutines/CoroEarly.cpp (diff)
The file was modifiedllvm/test/Transforms/Coroutines/coro-early.ll (diff)
Commit 0e2eb357e0471bbac81f18097e5ad761ae1431f0 by Matthew.Arsenault
GlobalISel: Extend narrowing to G_ASHR
The file was modifiedllvm/lib/Target/AMDGPU/AMDGPUPreLegalizerCombiner.cpp (diff)
The file was addedllvm/test/CodeGen/AMDGPU/GlobalISel/combine-ashr-narrow.mir
The file was modifiedllvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp (diff)
Commit cef85193b2cc1817ca43199a0ae9c6f25723997d by luismarques
[CMake] CheckAtomic.cmake: catch false positives in RISC-V

The check for 'HAVE_CXX_ATOMICS_WITHOUT_LIB' may create false
positives in RISC-V. This is reproducible when compiling LLVM natively
using GCC on a rv64gc (rv64imafdgc) host. Due to the 'A' (atomic)
extension, g++ replaces calls to libatomic operations on the
std::atomic<int> type with the native hardware instructions. As a
result, the compilation succeeds and the build system thinks it
doesn't need to pass '-latomic'.

Improve the reliability of the 'HAVE_CXX_ATOMICS_WITHOUT_LIB' test in
two steps:

1. Force a pre-increment on x (++x), which should force a call to a
libatomic function;

2. Because step 1 would resolve the increment to '' under
the 'A' extension, force the same operation on sub-word types, for
which there is no hardware support.

Reviewers: jfb, hintonda, smeenai, mgorny, JDevlieghere, jyknight
Reviewed By: jfb
Tags: #llvm
Differential Revision:
The file was modifiedllvm/cmake/modules/CheckAtomic.cmake (diff)
Commit 96db12d507fbac8b67278775d3234fa9b8178d22 by Matthew.Arsenault
AMDGPU/GlobalISel: Custom lower 32-bit G_UDIV/G_UREM

AMDGPUCodeGenPrepare expands this most of the time, but not always. We
will always at least need a fallback option here. This is the 3rd
implementation of the same expansion in the backend. Eventually I
would like to eliminate the IR expansion (and the DAG version

Currently the new legalizer path produces a better result, since the
IR expansion results in extra operations which need to be combined
out. Notably, the IR expansion results in multiplies by 0.
The file was modifiedllvm/test/CodeGen/AMDGPU/GlobalISel/legalize-urem.mir (diff)
The file was modifiedllvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.h (diff)
The file was modifiedllvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp (diff)
The file was modifiedllvm/test/CodeGen/AMDGPU/GlobalISel/legalize-udiv.mir (diff)
The file was modifiedllvm/test/CodeGen/AMDGPU/GlobalISel/legalize-sdiv.mir (diff)
The file was modifiedllvm/test/CodeGen/AMDGPU/GlobalISel/legalize-srem.mir (diff)
The file was addedllvm/test/CodeGen/AMDGPU/GlobalISel/urem.i32.ll
The file was addedllvm/test/CodeGen/AMDGPU/GlobalISel/udiv.i32.ll