[clang-tidy] Fix OOB access in `FormatStringConverter` with signed chars (#169215)
`FormatStringConverter::appendFormatText` incorrectly treated non-ASCII
characters (e.g. UTF-8) as negative values when using signed chars. This
caused them to pass the `< 32` check for control characters.
The negative values were passed to `llvm::hexdigit`, resulting in an OOB
access and a crash.
This closes
[#169198](https://github.com/llvm/llvm-project/issues/169198)
[RegAlloc] Relax the split constrain on MBB prolog (#168259)
https://reviews.llvm.org/D52052 is to prevent register split on the MBB
which have prolog instructions defining the exec register (or mask register
that activate the threads of a warp in GPU). The constrain seems too
strict, because 1) If the split is allowed, it may fit the free live range
of a physical register, and no spill will happen; 2) The register class of
register that is under splitting may not be the same to the register that
is defined in prolog, so there is no interference with the register being
defined in prolog.
The current code has another small issue. The MBB->getFirstNonDebugInstr()
just skip debug instructions, but SA->getFirstSplitPoint(Number) would skip
label and phi instructions. This cause some MBB with label instruction
being taken as prolog.
This patch is to relax the split constrain on MMB with prolog by checking
if the register defined in prolog has the common register class with the
register being split. It allow the split if the register defined in prolog
is physical register or there is no common register class.
[2 lines not shown]
[LV] Vectorize selecting last IV of min/max element. (#141431)
Add support for vectorizing loops that select the index of the minimum
or maximum element. The patch implements vectorizing those patterns by
combining Min/Max and FindFirstIV reductions.
It extends matching Min/Max reductions to allow in-loop users that are
FindLastIV reductions. It records a flag indicating that the Min/Max
reduction is used by another reduction. The extra user is then check as
part of the new `handleMultiUseReductions` VPlan transformation.
It processes any reduction that has other reduction users. The reduction
using the min/max reduction currently must be a FindLastIV reduction,
which needs adjusting to compute the correct result:
1. We need to find the last IV for which the condition based on the
min/max reduction is true,
2. Compare the partial min/max reduction result to its final value and,
3. Select the lanes of the partial FindLastIV reductions which
correspond to the lanes matching the min/max reduction result.
[3 lines not shown]
[GOFF] Write out relocations in the GOFF writer
Add support for writing relocations. Since the symbol numbering is only
available after the symbols are written, the relocations are collected
in a vector. At write time, the relocations are converted using the
symbols ids, compressed and written out. A relocation data record is
limited to 32K-1 bytes, which requires making sure that larger relocation
data is written into multiple records.
[MC] [Win64EH] Fix the operator ordering for UOP_SaveFPLRX. NFC.
The encoded offset should be (OffsetInBytes/8)-1 due to an
implicit offset of 1. Previously the operator ordering was
inverted. As the offset is a multiple of 8, the incorrect
operator ordering did produce the right result in all cases
anyway.
[MLIR][Transform] Return empty handles when the included sequence fails (#169782)
This fixes a bug in the interpreter for transform.include op, which
crashes when attempting to copy out the handles from the yield op of a
failing sequence.
[clang][NFC] Declare `CXXBasePaths::isAmbiguous` as `const`
To make this change, we have to use `lookup` instead of `operator[]` on a map. They both return the same thing: a default constructed value. The difference is that `lookup` default constructs a value and then returns it, whereas `operator[]` default constructs a value, inserts it into the map, and then returns a reference to that. Given that we are using a by-value return, the only way this is different is if a later use of the map depends on a value being at that key.
The map is a private variable of the class, so the only possible users are are other member functions. The only other use of the map that cares about the contents of the map is in `lookupInBases`, and it accesses the map with `operator[]`. This means that attempting to access the same element in this function will default construct the value before doing anything with it, which means it would do the exact thing it needs to do in the case where we are looking up a non-existent key, therefore no behavior has changed.
In terms of performance, this would either be a win or neutral. The benefit is that in some cases, we can avoid a memory allocation just read the contents of a 32-bit `0`. If a call to `isAmbiguous` is always followed up with a call to `lookupInBases`, then we allocate the memory just a little bit later for no difference in performance.
