SuccessChanges

Summary

  1. [APInt] New member function setBitVal (details)
  2. [PowerPC] Do not legalize vector FDIV without VSX (details)
  3. [mlir][Affine] Fix AffineLoopInvariantCodeMotion (details)
  4. Revert "[clang] Add missing .def files to Clang's modulemap" (details)
  5. Perform an extra consistency check when searching ModuleManager's (details)
Commit 099c089d4b4117fd654aa6e4dd544d7680fa80b9 by jay.foad
[APInt] New member function setBitVal

Differential Revision: https://reviews.llvm.org/D87033
The file was modifiedllvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
The file was modifiedllvm/include/llvm/ADT/APInt.h
The file was modifiedllvm/lib/MCA/HardwareUnits/RegisterFile.cpp
The file was modifiedllvm/lib/Support/APInt.cpp
Commit 27714075848e7f05a297317ad28ad2570d8e5a43 by nemanja.i.ibm
[PowerPC] Do not legalize vector FDIV without VSX

Quite a while ago, we legalized these nodes as we added custom
handling for reciprocal estimates in the back end. We have since
moved to target-independent combines but neglected to turn off
legalization. As a result, we can now get selection failures on
non-VSX subtargets as evidenced in the listed PR.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=47373
The file was modifiedllvm/lib/Target/PowerPC/PPCISelLowering.cpp
The file was addedllvm/test/CodeGen/PowerPC/pr47373.ll
Commit 65f20ea1133b3111a982c76eea74a609fa083184 by diego.caballero
[mlir][Affine] Fix AffineLoopInvariantCodeMotion

Make sure that memory ops that are defined inside the loop are registered
as such in 'defineOp'. In the test provided, the 'mulf' op was hoisted
outside the loop nest even when its 'affine.load' operand was not.

Reviewed By: bondhugula

Differential Revision: https://reviews.llvm.org/D86982
The file was modifiedmlir/test/Dialect/Affine/affine-loop-invariant-code-motion.mlir
The file was modifiedmlir/lib/Dialect/Affine/Transforms/AffineLoopInvariantCodeMotion.cpp
Commit 3b12e12d4b9efbdd28113da6db0f74b660257c83 by Adrian Prantl
Revert "[clang] Add missing .def files to Clang's modulemap"

This reverts commit e0e7eb2e2648aee83caf2ecfe2972ce2f653d306.

[the commit this fixes up was reverted]
The file was modifiedclang/include/clang/module.modulemap
Commit 272742a92d2443893eb98a7b3460e243e34278f9 by Adrian Prantl
Perform an extra consistency check when searching ModuleManager's
cache for implicit modules.

The ModuleManager's use of FileEntry nodes as the keys for its map of
loaded modules is less than ideal. Uniqueness for FileEntry nodes is
maintained by FileManager, which in turn uses inode numbers on hosts
that support that. When coupled with the module cache's proclivity for
turning over and deleting stale PCMs, this means entries for different
module files can wind up reusing the same underlying inode. When this
happens, subsequent accesses to the Modules map will disagree on the
ModuleFile associated with a given file.

In general, it is not sufficient to resolve this conundrum with a type
like FileEntryRef that stores the name of the FileEntry node on first
access because of path canonicalization issues. However, the paths
constructed for implicit module builds are fully under Clang's
control. We *can*, therefore, rely on their structure being consistent
across operating systems and across subsequent accesses to the Modules
map.

To mitigate the effects of inode reuse, perform an extra name check when
implicit modules are returned from the cache. This has the effect of
forcing reused FileEntry nodes to stomp over existing-but-stale entries
in the cache, which simulates a miss - exactly the desired behavior.

rdar://48443680

Patch by Robert Widmann!

Differential Revision: https://reviews.llvm.org/D86823
The file was modifiedclang/lib/Serialization/ModuleManager.cpp