[AutoBump] Bump to 6bec4fc7 (1) #248
Merged
Conversation
This file contains 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
As noted in llvm#84035 (comment) only files under the CPP folder should be in the `cpp` namespace.
GCC complains if we pass -Werror=format-security without -Wformat. Reported at llvm#83779 (comment)
llvm-project/clang/lib/Sema/SemaChecking.cpp:19192:15:
error: unused variable 'Field1Parent' [-Werror,-Wunused-variable]
const Type *Field1Parent = Field1->getParent()->getTypeForDecl();
^
llvm-project/clang/lib/Sema/SemaChecking.cpp:19193:15:
error: unused variable 'Field2Parent' [-Werror,-Wunused-variable]
const Type *Field2Parent = Field2->getParent()->getTypeForDecl();
^
2 errors generated.
Add neon bici test for haddu and shadd, prerequisite for llvm#76644
Similar to llvm#84187, this enables the existing test we have for checking the scheduling info of the pseudos matches the real instructions, and adjusts the scheduling info in the NeoverseN2 model to make sure all cases were handled.
Pattern should be sorted in priority order since the pattern evalutor stops checking as soon as it finds a faster sequence. so for a * b - c * d, we prefer to match the 2nd operands of sub, which can be use msub to fold them. Refer to https://www.slideshare.net/chimerawang/instruction-combine-in-llvm Fix llvm#84152
This will be useful for OpenMP too. I changed the definition slightly to use `fir::isa_ref_type` (which also includes llvm pointers) because I think it reads better using the common type helpers. There shouldn't be any llvm pointers in lowering so this isn't a functional change.
…llvm#84305) TBAA builder assumed that all loads/stores are inside of functions and hit an assertion once it found loads and stores inside of an omp::ReductionDeclareOp. For now just don't add TBAA tags to those loads and stores. They would end up in a different TBAA tree to the host function after OpenMPIRBuilder inlines them anyway so there isn't an easy way of making this work.
Second attempt.
* gmake is needed on FreeBSD * pkg can install libxml2 on FreeBSD * Make the swig note into an RST note box.
Second attempt. This also reverts 5063386.
…ueDecl with template arguments (llvm#83842)" (llvm#84457) This reverts commit a642eb8 (see llvm#83842)
…ern `static_assert` (llvm#77584) static_assert is supported in all modes, so the T/F macros aren't needed anymore.
This explains a thing that hit me on FreeBSD because the base system has an ncursesw at one version and I installed from pkg another version that was simply ncurses (no wide char support). For whatever reason, when we pass -lcurses to the linker it ends up picking bits of both installs. This led to lldb crashing immediately if you tried to use the `gui` command. In a way that gave little information but I stumbled onto vifm/vifm#325 which is very similar. ``` ec2-user@freebsd:~/build-llvm $ ldd ./bin/lldb | grep curses libncursesw.so.9 => /lib/libncursesw.so.9 (0x6a515206e000) libncurses.so.6 => /usr/local/lib/libncurses.so.6 (0x6a5158e86000) ``` We should only see one version, and it and libpanel etc should all have "w" or not have "w". This was not the case for my build. What I can see from the CMake side seemed fine, it found the pkg installed ncurses in /usr/local. Something else must decide that -lcurses should pull in the other one. Regardless, I don't know how to fix that but the solution for most people is just not to add another ncurses if they already have one. So I've added a note saying so, and how to check what your lldb is using.
…h call. (llvm#83859) This removes, at least when a vector library is available, a failure case for scalable vectors. Doing so means we can confidently cost vector FREM instructions without making an assumption that later passes will transform the IR before it gets to the code generator. NOTE: Whilst only FREM has been implemented the same mechanism can be used for the other libm related ISD nodes.
…lvm#84459) We don't modify the MLTAL parameter in `SetupConstraintScope`, and it is better if we don't copy the 120-byte object each time we call the function.
APX assembly syntax recommendations: https://cdrdv2.intel.com/v1/dl/getContent/817241 NOTE: The change in llvm/tools/llvm-exegesis/lib/X86/Target.cpp is for test LLVM :: tools/llvm-exegesis/X86/latency/latency-SETCCr-cond-codes-sweep.s For `SETcc`, llvm-exegesis would randomly choose 1 other instruction to test with `SETcc`, after selecting the instruction, llvm-exegesis would check if the operand is initialized and valid, if not `randomizeTargetMCOperand` would choose a value for invalid operand, it misses support for condition code operand, which cause the flaky failure after `CCMP` supported. llvm-exegesis can choose `CCMP` without specifying ccmp feature b/c it use `MCSubtarget` and only16/32/64 bit is considered. llvm-exegesis doesn't choose other instructions b/c requirement in `hasAliasingRegistersThrough`: the instruction should use GPR (defined by `SETcc`) and define `EFLAGS` (used by `SETcc`).
Summary: This default enum is used in other places, we should keep it consistent.
…llvm#84446) Note that this patch will be necessary to fix `forEachArgumentWithParam()` and `forEachArgumentWithParamType()` matchers for deducing "this"; which is my true motivation. There the bug is that with explicit obj params, one should not adjust the number of arguments in presence of `CXXMethodDecls`, and this causes a mismatch there mapping the argument to the wrong param. But, I'll come back there once we have this matcher.
Its sole user is `BigInt` so moving `full_mul` inside UInt.h.
This commit adds two new notifications to `RewriterBase::Listener`: * `notifyPatternBegin`: Called when a pattern application begins during a greedy pattern rewrite or dialect conversion. * `notifyPatternEnd`: Called when a pattern application finishes during a greedy pattern rewrite or dialect conversion. The listener infrastructure already provides a `notifyMatchFailure` callback that notifies about the reason for a pattern match failure. The two new notifications provide additional information about pattern applications. This change is in preparation of improving the handle update mechanism in the `apply_conversion_patterns` transform op.
The previous code would truncate IntegerAPs wider than 64 bits.
…gen output for the `checkPredicate` function is deterministic (llvm#84533) The output for the `checkPredicate` function was depending on a `std::map` iteration that was non-deterministic from run to run, because the keys were pointer values. Make a change so that the keys are `StringRef`s so the ordering is stable.
…c macros (llvm#84659) Fixes llvm#84658. Assuming these were typos in the first place. I am unsure of the best way to ensure that both sides of the preprocessor condition in `libc/include/llvm-libc-macros/stdbit-macros.h` are tested. Could someone point me in the right direction for adding test coverage to the non `__cplusplus` branch? Or maybe it is being tested and I've missed it.
…ange metadata (llvm#84673) Found that this failed with an assertion when vec was used in this optimization while working on llvm#84627.
MLIROpenACCTransforms does not use the LLVMIR dialect yet includes LLVMIR headers. This causes building MLIROpenACCTransforms only from a clean build to fail with: In file included from mlir/lib/Dialect/OpenACC/Transforms/LegalizeData.cpp:9: In file included from mlir/include/mlir/Dialect/OpenACC/Transforms/Passes.h:12: mlir/include/mlir/Dialect/LLVMIR/Transforms/AddComdats.h:21:10: fatal error: 'mlir/Dialect/LLVMIR/Transforms/Passes.h.inc' file not found This patch removes the problematic includes.
Summary: Cleans up two warnings I get locally while building.
…86ISD::ANDNP target nodes Fixes llvm#84660
After llvm#84657 was merged, [buildbot](https://lab.llvm.org/buildbot/#/builders/250/builds/19808) is reporting two errors for libc-x86_64-debian-gcc-fullbuild-dbg. This PR addresses the truncation error for `CPP::bit_ceil<unsigned char>` and `CPP::bit_ceil<unsigned short>`. The errors are: ``` FAILED: projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_uc.dir/stdc_bit_ceil_uc.cpp.o /usr/bin/g++ -DLIBC_NAMESPACE=__llvm_libc_19_0_0_git -D_DEBUG -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/projects/libc/src/stdbit -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc -isystem /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/projects/libc/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-vir! tual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -fpie -ffreestanding -fno-builtin -fno-exceptions -fno-lax-vector-conversions -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-rtti -ftrivial-auto-var-init=pattern -Wall -Wextra -Werror -Wconversion -Wno-sign-conversion -Wimplicit-fallthrough -Wwrite-strings -Wextra-semi -DLIBC_COPT_PUBLIC_PACKAGING -std=c++17 -MD -MT projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_uc.dir/stdc_bit_ceil_uc.cpp.o -MF projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_uc.dir/stdc_bit_ceil_uc.cpp.o.d -o projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_uc.dir/stdc_bit_ceil_uc.cpp.o -c /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_uc.cpp In file included from /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_uc.cpp:11: /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/CPP/bit.h: In instantiation of ‘constexpr __llvm_libc_19_0_0_git::cpp::enable_if_t<is_unsigned_v<T>, T> __llvm_libc_19_0_0_git::cpp::bit_ceil(T) [with T = unsigned char; enable_if_t<is_unsigned_v<T>, T> = unsigned char]’: /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_uc.cpp:17:23: required from here /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/CPP/bit.h:196:57: error: conversion from ‘unsigned int’ to ‘unsigned char’ may change value [-Werror=conversion] 196 | return static_cast<T>(T(1) << cpp::bit_width<T>(value - 1u)); | ~~~~~~^~~~ cc1plus: all warnings being treated as errors [138/466] Building CXX object projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_us.dir/stdc_bit_ceil_us.cpp.o FAILED: projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_us.dir/stdc_bit_ceil_us.cpp.o /usr/bin/g++ -DLIBC_NAMESPACE=__llvm_libc_19_0_0_git -D_DEBUG -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/projects/libc/src/stdbit -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit -I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc -isystem /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/projects/libc/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-vir! tual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -fpie -ffreestanding -fno-builtin -fno-exceptions -fno-lax-vector-conversions -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-rtti -ftrivial-auto-var-init=pattern -Wall -Wextra -Werror -Wconversion -Wno-sign-conversion -Wimplicit-fallthrough -Wwrite-strings -Wextra-semi -DLIBC_COPT_PUBLIC_PACKAGING -std=c++17 -MD -MT projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_us.dir/stdc_bit_ceil_us.cpp.o -MF projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_us.dir/stdc_bit_ceil_us.cpp.o.d -o projects/libc/src/stdbit/CMakeFiles/libc.src.stdbit.stdc_bit_ceil_us.dir/stdc_bit_ceil_us.cpp.o -c /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_us.cpp In file included from /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_us.cpp:11: /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/CPP/bit.h: In instantiation of ‘constexpr __llvm_libc_19_0_0_git::cpp::enable_if_t<is_unsigned_v<T>, T> __llvm_libc_19_0_0_git::cpp::bit_ceil(T) [with T = short unsigned int; enable_if_t<is_unsigned_v<T>, T> = short unsigned int]’: /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/stdbit/stdc_bit_ceil_us.cpp:17:23: required from here /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/CPP/bit.h:196:57: error: conversion from ‘unsigned int’ to ‘short unsigned int’ may change value [-Werror=conversion] 196 | return static_cast<T>(T(1) << cpp::bit_width<T>(value - 1u)); | ~~~~~~^~~~ cc1plus: all warnings being treated as errors ```
Summary: This header isn't strictly necessary, and is currently broken because we install these to separate locations.
Make recursive matcher that is able to detect a lot more patterns. Proofs for all supported patterns: https://alive2.llvm.org/ce/z/fSQ3nZ Differential Revision: https://reviews.llvm.org/D159058
…foldICmpWithLowBitMaskedVal` `(icmp eq/ne (and X, ~Mask), 0)` is equivilent to `(icmp eq/ne (and X, Mask), X` and we sometimes generate the former pattern intentionally to reduce number of uses of `X`. Proof: https://alive2.llvm.org/ce/z/3u-usC Differential Revision: https://reviews.llvm.org/D159329 Closes llvm#81562
…lvm#83878) Currently ObjCStubsSection is handling both the logic for the "__objc_stubs" section, as well as the logic for the "__objc_selrefs" section. While this is OK for now, it will be an issue for other features that want to interact with the "__objc_selrefs" section, such as upcoming relative method lists feature - which will also want to create / reference entries in the "__objc_selrefs" section. In this PR we split the logic relating to handling the "__objc_selrefs" section into a new SyntheticSection (ObjCSelRefsSection). Non-functional change - neither the behavior nor implementation changes, the interface is just made more friendly to not have "__objc_selrefs" so bound to "__objc_stubs". --------- Co-authored-by: Alex B <alexborcan@meta.com>
…84690) Summary: This is a NFC move preceding more radical functional changes to the allocator implementation. We just move it to a common utility so it will be easier to write these in tandem.
Implement `msync` as specified in: 1. https://www.man7.org/linux/man-pages/man2/msync.2.html 2. https://pubs.opengroup.org/onlinepubs/9699919799/
llvm#83211) This allows handling importlibs produced by llvm-dlltool in llvm#78772. ARM64EC import libraries use it by default, but it's supported by MSVC link.exe on other platforms too. This also avoids assuming null-terminated input, like in llvm#78769.
…cmp eq/ne (lshr Y, X), 0)`; NFC
…q/ne (lshr Y, X), 0)` Proofs: https://alive2.llvm.org/ce/z/oSRGBt Closes llvm#84691
…rrect `MSB` value (llvm#84454) The `MSB` must not be greater than `GRLen`. Without this patch, newly added test cases will crash with LoongArch32, resulting in a 'cannot select' error.
Implement `llvm.coro.await.suspend` intrinsics, to deal with performance regression after prohibiting `.await_suspend` inlining, as suggested in llvm#64945. Actually, there are three new intrinsics, which directly correspond to each of three forms of `await_suspend`: ``` void llvm.coro.await.suspend.void(ptr %awaiter, ptr %frame, ptr @wrapperFunction) i1 llvm.coro.await.suspend.bool(ptr %awaiter, ptr %frame, ptr @wrapperFunction) ptr llvm.coro.await.suspend.handle(ptr %awaiter, ptr %frame, ptr @wrapperFunction) ``` There are three different versions instead of one, because in `bool` case it's result is used for resuming via a branch, and in `coroutine_handle` case exceptions from `await_suspend` are handled in the coroutine, and exceptions from the subsequent `.resume()` are propagated to the caller. Await-suspend block is simplified down to intrinsic calls only, for example for symmetric transfer: ``` %id = call token @llvm.coro.save(ptr null) %handle = call ptr @llvm.coro.await.suspend.handle(ptr %awaiter, ptr %frame, ptr @wrapperFunction) call void @llvm.coro.resume(%handle) %result = call i8 @llvm.coro.suspend(token %id, i1 false) switch i8 %result, ... ``` All await-suspend logic is moved out into a wrapper function, generated for each suspension point. The signature of the function is `<type> wrapperFunction(ptr %awaiter, ptr %frame)` where `<type>` is one of `void` `i1` or `ptr`, depending on the return type of `await_suspend`. Intrinsic calls are lowered during `CoroSplit` pass, right after the split. Because I'm new to LLVM, I'm not sure if the helper function generation, calls to them and lowering are implemented in the right way, especially with regard to various metadata and attributes, i. e. for TBAA. All things that seemed questionable are marked with `FIXME` comments. There is another detail: in case of symmetric transfer raw pointer to the frame of coroutine, that should be resumed, is returned from the helper function and a direct call to `@llvm.coro.resume` is generated. C++ standard demands, that `.resume()` method is evaluated. Not sure how important is this, because code has been generated in the same way before, sans helper function.
cferry-AMD
approved these changes
Aug 12, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.