Isoard.upstream sync2#606
Merged
Merged
Conversation
…f-stabs (#116687) Currently when `--icf=safe_thunks` is used, `STABS` entries cannot be generated for ICF'ed functions. This is because if ICF converts a full function into a thunk and then we generate a `STABS` entry for the thunk, `dsymutil` will expect to find the entire function body at the location of the thunk. Because just a thunk will be present at the location of the `STABS` entry - dsymutil will generate invalid debug info for such scenarios. With this change, if `--icf=safe_thunks` is used and `--keep-icf-stabs` is also specified, STABS entries will be created for all functions, even merged ones. However, the STABS entries will point at the actual (full) function body while having the name of the thunk. This way we still get program correctness as well as correct DWARF data. When doing this, the debug data will be identical to the scenario where we're using `--icf=all` and `--keep-icf-stabs`, but the actual program will also contain thunks, which won't show up in the DWARF data.
Unbeknownst to me the Swift LLDB branch already had an almost identical API with this name, so it makes sense to merge the two.
vector.match was added in e52238. extract.last.active was added in ed5aad. We have oppurtunities for better codegen in both, but neither are terrible out of the box.
One last diff I missed between Swift and LLVM.
Prepare for usage in the bitcode reader/writer where we already have a LinearFrameId: - templatize input frame id type in CallStackRadixTreeBuilder - templatize input frame id type in computeFrameHistogram - make the map from FrameId to LinearFrameId optional We plan to use the same radix format in the ThinLTO summary records, where we already have a LinearFrameId.
While addressing code review feedback I accidentally introduced a spurious second newline.
…Split (#116879) Avoid repeated calls to value() and index() using structured binding with llvm::enumerate.
This patch updates a unit test to construct MemProfReader with IndexedMemProfData, a complete package of MemProf profile. With this change, nobody in the LLVM codebase is using the MemProfReader constructor that takes individual components of the MemProf profile, so this patch deprecates the constructor.
Fully OOT build along with SCUDO: ``` mkdir oot cp -r cmake libc compiler-rt oot cp ./llvm/cmake/modules/* ./oot/cmake/Modules/ cd oot mkdir build cd build cmake ../libc -DLIBC_USE_NEW_HEADER_GEN=On -DLLVM_LIBC_FULL_BUILD=On -DLLVM_LIBC_FULL_BUILD=On -DLLVM_LIBC_INCLUDE_SCUDO=On -DCOMPILER_RT_BUILD_SCUDO_STANDALONE_WITH_LLVM_LIBC=On -DCOMPILER_RT_SCUDO_STANDALONE_BUILD_SHARED=Off -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DLLVM_LIBC_COMPILER_RT_PATH=../compiler-rt/ -DCOMPILER_RT_STANDALONE_BUILD=On -GNinja -DLLVM_COMPILER_IS_GCC_COMPATIBLE=On -DLLVM_RUNTIMES_BUILD=On ```
Preserve tbaa metadata on the replacement instruction, if it does not move. In that case, the program would be UB, if the aliasing property encoded in the metadata does not hold. This makes use of the clarification re tbaa metadata implying UB if the property does not hold: llvm/llvm-project#116220 Same as llvm/llvm-project#115868, but for !tbaa PR: llvm/llvm-project#116682
Add IsText parameter to open yaml file this fixes `FAIL: LLVM :: Transforms/LowerTypeTests/cfi-icall-alias.ll` Co-authored-by: Abhina Sreeskantharajan <Abhina.Sreeskantharajan@ibm.com>
…eeds (#116891) Load/Store isSimple is a necessary condition for VectorSeeds, but not sufficient, so reverse the condition and return value, and continue the check. Add relevant tests.
arm-polly-linux seems to be failing because we don't include <unordered_map>. https://lab.llvm.org/buildbot/#/builders/90/builds/3090
Use ULEB128 encoding for call sites in PIE/DSO binaries. The encoding reduces the size of the tables compared to sdata4 and is the default format used by Clang. Note that for fixed-address executables we still use absolute addressing to cover cases where landing pads can reside in different function fragments. For testing, we rely on runtime EH tests.
…truction. NFC. Looks like this one is the odd one out. Doesn't affect any functionality and now matches the naming convention of the other type variants.
This is a NFC change to fix a typo in dasm test of VOPC instructions. Fake16 test should use "-real-true16" attribute. Test are passing previously because the true16 of VOPC instructions are not yet implemented
We've switched to LineLocation from FieldsAre in MemProfUseTest.cpp. This patch does the same thing in InstrProfTest.cpp. llvm/unittests/Transforms/Instrumentation/MemProfUseTest.cpp
…` (#115627)
This fixes a missed optimization caused by the `foldBitcastExtElt`
pattern interfering with other combine patterns. In the case I was
hitting, we have IR that combines two vectors into a new larger vector
by extracting elements and inserting them into the new vector.
```llvm
define <4 x half> @bitcast_extract_insert_to_shuffle(i32 %a, i32 %b) {
%avec = bitcast i32 %a to <2 x half>
%a0 = extractelement <2 x half> %avec, i32 0
%a1 = extractelement <2 x half> %avec, i32 1
%bvec = bitcast i32 %b to <2 x half>
%b0 = extractelement <2 x half> %bvec, i32 0
%b1 = extractelement <2 x half> %bvec, i32 1
%ins0 = insertelement <4 x half> undef, half %a0, i32 0
%ins1 = insertelement <4 x half> %ins0, half %a1, i32 1
%ins2 = insertelement <4 x half> %ins1, half %b0, i32 2
%ins3 = insertelement <4 x half> %ins2, half %b1, i32 3
ret <4 x half> %ins3
}
```
With the current behavior, `InstCombine` converts each vector extract
sequence to
```llvm
%tmp = trunc i32 %a to i16
%a0 = bitcast i16 %tmp to half
%a1 = extractelement <2 x half> %avec, i32 1
```
where the extraction of `%a0` is now done by truncating the original
integer. While on it's own this is fairly reasonable, in this case it
also blocks the pattern which converts `extractelement` -
`insertelement` into shuffles which gives the overall simpler result:
```llvm
define <4 x half> @bitcast_extract_insert_to_shuffle(i32 %a, i32 %b) {
%avec = bitcast i32 %a to <2 x half>
%bvec = bitcast i32 %b to <2 x half>
%ins3 = shufflevector <2 x half> %avec, <2 x half> %bvec, <4 x i32> <i32 0, i32 1, i32 2, i32 3>
ret <4 x half> %ins3
}
```
In this PR I fix the conflict by obeying the `hasOneUse` check even if
there is no shift instruction required. In these cases we can't remove
the vector completely, so the pattern has less benefit anyway.
Also fwiw, I think dropping the `hasOneUse` check for the 0th element
might have been a mistake in the first place. Looking at
llvm/llvm-project@535c5d5
the commit message only mentions loosening the `isDesirableIntType`
requirement and doesn't mention changing the `hasOneUse` check at all.
Release note #110646 and #114507.
Instead of custom selecting a bunch of instructions, we can expand to generic MIR during legalization.
This reworks the free store implementation in libc's malloc to use a dlmalloc-style binary trie of circularly linked FIFO free lists. This data structure can be maintained in logarithmic time, but it still permits a relatively small implementation compared to other logarithmic-time ordered maps. The implementation doesn't do the various bitwise tricks or optimizations used in actual dlmalloc; it instead optimizes for (relative) readability and minimum code size. Specific optimization can be added as necessary given future profiling.
…#117065) Reverts llvm/llvm-project#106259 Unit tests break on AArch64.
This patch upgrades a unit test to MemProf Version 3 while removing those bits that cannot be upgraded to Version 3. The bits being removed expect instrprof_error::hash_mismatch from a broken MemProf profile that references a frame that doesn't actually exist. Now, Version 3 no longer issues instrprof_error::hash_mismatch. Even if it still issued instrprof_error::hash_mismatch, we would have a couple of hurdles: - InstrProfWriter::addMemProfData will soon require all (or none) of the fields (frames, call stacks, and records) be populated. That is, it won't accept an instance of IndexedMemProfData with frames missing. - writeMemProfV3 asserts that every frame occurs at least once: assert(MemProfData.Frames.size() == FrameHistogram.size()); This patch gives up on instrprof_error::hash_mismatch and tries to trigger instrprof_error::unknown_function with the empty profile.
The Android clang-r536225 compiler identifies as Clang 19, but it is based on commit fc57f88, which predates the official LLVM 19.0.0 release. Some tests need fixes: * The sized delete tests fail because clang-r536225 leaves sized deallocation off by default. * std::array<T[0]> is true when this Android Clang version is used with a trunk libc++, but we expect it to be false in the test. In practice, Clang and libc++ usually come from the same commit on Android.
…16151) Android clang-r536225 identifies as Clang 19 but it predates LLVM 19.0.0. It is based off of fc57f88.
…ames with DWARFTypePrinter (#117071) This is a reland of llvm/llvm-project#112811. Fixed the bot breakage by running ld.lld explicitly.
…alloca and malloc parameters bound" (#117020) Reverts llvm/llvm-project#115522 This caused UBSan errors in multi-stage clang build: https://lab.llvm.org/buildbot/#/builders/25/builds/4241/steps/10/logs/stdio
To prevent assertion failures when we disable implicit truncation in getConstant().
Only BinaryOperator and CastInst support alternate instruction. It always returns false for TreeEntry::isAltShuffle if an instruction is ExtractElementInst, ExtractValueInst, LoadInst, StoreInst or InsertElementInst.
isoard-amd
requested review from
F-Stuckmann,
SagarMaheshwari99,
abhinay-anubola,
abnikant,
andcarminati,
katerynamuts,
khallouh,
konstantinschwarz,
martien-de-jong,
niwinanto,
philippjh and
stephenneuendorffer
as code owners
added 7 commits
August 7, 2025 19:05
isoard-amd
force-pushed
the
isoard.upstream-sync2
branch
from
d284db1 to
632dcd1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.