[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

@@ -0,0 +1,52 @@ +// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --filter "call.*(frexp|modf)" --version 4 +// RUN: %clang --target=aarch64-linux-gnu -march=armv8-a+sve -O3 -isystem %S/../Headers/Inputs/include -mllvm

[clang] [clang] Preserve found-decl when constructing VarTemplateIds (PR #82265)

nikic wrote: I think this commit is responsible for the ClangIncludeCleaner test failure. https://github.com/llvm/llvm-project/pull/82265 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Driver] Remove dead -freroll-loops flag (PR #82254)

https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/82254 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver] Remove dead -freroll-loops flag (PR #82254)

@@ -3871,10 +3871,6 @@ def funroll_loops : Flag<["-"], "funroll-loops">, Group, HelpText<"Turn on loop unroller">, Visibility<[ClangOption, CC1Option]>; def fno_unroll_loops : Flag<["-"], "fno-unroll-loops">, Group, HelpText<"Turn off loop unroller">,

[clang] [Driver] Remove dead -freroll-loops flag (PR #82254)

https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/82254 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver] Remove dead -freroll-loops flag (PR #82254)

https://github.com/nikic created https://github.com/llvm/llvm-project/pull/82254 Remove the `-freroll-loops` flag, which has not had any effect since the migration to the new pass manager. The underlying pass has been removed entirely in #80972 due to lack of maintenance and known bugs. >From

[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)

nikic wrote: > > It should be technically possible for Clang to give _BitInt(N) an alignment > > that is independent from LLVM's alignment > > I'm not sure it's even technically possible: if loading a `_BitInt(129)` from > memory should load 3 bytes, but it is translated to an LLVM IR load of

[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)

nikic wrote: Thanks for providing proper context. The second issue does look pretty serious to me. It's a regression from the i128 alignment changes in LLVM 18. It should be technically possible for Clang to give `_BitInt(N)` an alignment that is independent from LLVM's alignment, but clearly

[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)

https://github.com/nikic dismissed https://github.com/llvm/llvm-project/pull/81175 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)

https://github.com/nikic requested changes to this pull request. I don't think that this makes sense, given that this has already been allowed in previous stable clang releases. That's not a step you can really take back. > but internal compiler errors and seriously wrong code I find your PR

[clang] [Clang][CodeGen] Loose the cast check when emitting builtins (PR #81669)

nikic wrote: > I think the right fix is teaching that function about FP <-> INT casts. The documentation for that function says: ``` /// Return true if this type could be converted with a lossless BitCast to /// type 'Ty'. For example, i8* to i32*. BitCasts are valid for types of the ///

[clang] [flang] [llvm] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

nikic wrote: @Artem-B I've put up https://github.com/llvm/llvm-project/pull/80983 to address this issue. https://github.com/llvm/llvm-project/pull/68882 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang-tools-extra] [clangd] [C++20] [Modules] Introduce initial support for C++20 Modules (PR #66462)

https://github.com/nikic demilestoned https://github.com/llvm/llvm-project/pull/66462 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [flang] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

nikic wrote: @Artem-B Thanks for the report. SROA already has a bunch of special handling for `load(c ? p1 : p2)` as well as `load(gep(c ? p1 : p2, idx))`, so it's probably not too hard to also support `load(gep(p, c ? idx1 : idx2))`. In your particular case, it seems like it's actually

[clang] [Clang][CodeGen] Mark `__dynamic_cast` as `willreturn` (PR #80409)

https://github.com/nikic approved this pull request. LGTM, nice find! https://github.com/llvm/llvm-project/pull/80409 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Convert __builtin_dynamic_object_size into a calculation (PR #80256)

nikic wrote: (Dropping myself as reviewer as I'm not really familiar with clang.) Looks like this is missing test coverage? https://github.com/llvm/llvm-project/pull/80256 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang-tools-extra] [llvm] [clang] [SCEVExp] Keep NUW/NSW if both original inc and isomporphic inc agree. (PR #79512)

https://github.com/nikic approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/79512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [clang-tools-extra] [GitHub][workflows] Add buildbot information comment to first merged PR from a new contributor (PR #78292)

https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/78292 >From 20822b4a2f8e228365c8fa912af18afc9956749e Mon Sep 17 00:00:00 2001 From: David Spickett Date: Tue, 16 Jan 2024 13:36:15 + Subject: [PATCH 01/10] [GitHub][workflows] Add buildbot information comment to

[clang] Support C++20 Modules in clang-repl (PR #79261)

nikic wrote: > Until this change we sailed fairly well. It seems that the pcm rigorously > records the clang notion of the triple which is probably what we want. > However, if we are building a pcm in the context of `clang-repl` would it > make sense to use the `getProcessTriple` notion for

[clang] [Clang, SystemZ] Split test into Driver and CodeGen parts (NFC) (PR #79808)

https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/79808 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Support C++20 Modules in clang-repl (PR #79261)

nikic wrote: Normal clang creates a driver using the default target triple here: https://github.com/llvm/llvm-project/blob/754a8add57098ef71e4a51a9caa0cc175e94377d/clang/tools/driver/driver.cpp#L485 clang-repl appears to use IncrementalCompilerBuilder, which uses `getProcessTriple()` here:

[clang] [Clang, SystemZ] Split test into Driver and CodeGen parts (NFC) (PR #79808)

https://github.com/nikic created https://github.com/llvm/llvm-project/pull/79808 The test added in #73511 currently fails in CLANG_DEFAULT_PIE_ON_LINUX=OFF configuration, because it uses the clang driver in a codegen test. Split the test into two, a driver test that checks that the appropriate

[clang] [llvm] [flang] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/68882 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [Clang] Correct __builtin_dynamic_object_size for subobject types (PR #78526)

nikic wrote: Thanks for summarizing, that matches my understanding. As to how to implement this "properly", that would probably be https://discourse.llvm.org/t/exploring-the-effects-and-uses-of-the-memory-region-declaration-intrinsic/72756. The memory.region.decl intrinsics effectively encode

[clang] ea4d22f - [Lex] Avoid repeated calls to getIdentifierInfo() (NFC)

Author: Nikita Popov Date: 2024-01-23T12:16:14+01:00 New Revision: ea4d22f22568ccce7985032d150e79197694d38f URL: https://github.com/llvm/llvm-project/commit/ea4d22f22568ccce7985032d150e79197694d38f DIFF: https://github.com/llvm/llvm-project/commit/ea4d22f22568ccce7985032d150e79197694d38f.diff

[llvm] [clang] [clang][FatLTO] Avoid UnifiedLTO until it can support WPD/CFI (PR #79061)

nikic wrote: There's a merge conflict (probably after https://github.com/llvm/llvm-project/pull/79041). https://github.com/llvm/llvm-project/pull/79061 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang] Fix build with GCC 14 on ARM (PR #78704)

https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/78704 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [Clang] Correct __builtin_dynamic_object_size for subobject types (PR #78526)

nikic wrote: @bwendling I think you are reading the GCC docs too pedantically. In particular, they also say > If there are multiple objects ptr can point to and all of them are known at > compile time, the returned number is the maximum of remaining byte counts in > those objects if type & 2

[clang] [Clang] Fix build with GCC 14 on ARM (PR #78704)

@@ -760,8 +760,9 @@ KEYWORD(__builtin_available , KEYALL) KEYWORD(__builtin_sycl_unique_stable_name, KEYSYCL) // Keywords defined by Attr.td. +// The "EMPTY ## X" is used to prevent early macro-expansion of the keyword. #ifndef KEYWORD_ATTRIBUTE -#define

[clang] [Clang] Fix build with GCC 14 on ARM (PR #78704)

https://github.com/nikic created https://github.com/llvm/llvm-project/pull/78704 GCC 14 defines `__arm_streaming` as a macro expanding to `[[arm::streaming]]`. Due to the nested macro use, this gets expanded prior to concatenation. It doesn't look like C++ has a really clean way to prevent

[llvm] [clang-tools-extra] [clang] Move ExpandMemCmp and MergeIcmp to the middle end (PR #77370)

nikic wrote: @gbaraldi New compile-time numbers: https://llvm-compile-time-tracker.com/compare.php?from=ecd47811b755d13357085bcd7519a66d6c4d8e5c=f582b874c35e2b90046da8e8c30a7fa30ba08167=instructions:u (They are mildly positive now, and there are some text size reductions.)

[llvm] [clang] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

@@ -2274,6 +2274,26 @@ bool LoopAccessInfo::canAnalyzeLoop() { return true; } +/// Returns whether \p I is a known math library call that has attribute +/// 'memory(argmem: write)' set. +static bool isMathLibCallMemWriteOnly(const TargetLibraryInfo *TLI, +

[llvm] [flang] [clang] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

nikic wrote: @dtcxzyw I'm going to merge this after LLVM 18 branches next week. https://github.com/llvm/llvm-project/pull/68882 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [Clang] Correct __builtin_dynamic_object_size for subobject types (PR #78526)

https://github.com/nikic requested changes to this pull request. Using anything but the size and alignment of the alloca type in a way that affects program semantics is illegal. https://github.com/llvm/llvm-project/pull/78526 ___ cfe-commits mailing

[clang] [Clang] Set writable and dead_on_unwind attributes on sret arguments (PR #77116)

https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/77116 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add test for CWG1807 (PR #77637)

@@ -0,0 +1,31 @@ +// RUN: %clang_cc1 -std=c++98 %s -triple x86_64-linux-gnu -emit-llvm -o - -fexceptions -fcxx-exceptions -pedantic-errors | llvm-cxxfilt -n | FileCheck %s --check-prefixes CHECK,CXX98 +// RUN: %clang_cc1 -std=c++11 %s -triple x86_64-linux-gnu -emit-llvm -o -

[clang] [clang] Add test for CWG1807 (PR #77637)

@@ -0,0 +1,31 @@ +// RUN: %clang_cc1 -std=c++98 %s -triple x86_64-linux-gnu -emit-llvm -o - -fexceptions -fcxx-exceptions -pedantic-errors | llvm-cxxfilt -n | FileCheck %s --check-prefixes CHECK,CXX98 +// RUN: %clang_cc1 -std=c++11 %s -triple x86_64-linux-gnu -emit-llvm -o -

[clang] [Clang] Set writable and dead_on_unwind attributes on sret arguments (PR #77116)

nikic wrote: Some IR for reference: https://clang.godbolt.org/z/qEsP7vozW I believe that on unwind, the sret temporary is either entirely unused (if no cleanup landingpad is necessary) or we will call lifetime.end on it (which is legal for dead_on_unwind). This should be independent of

[clang] [llvm] [Clang] Update Unicode version to 15.1 (PR #77147)

nikic wrote: Ooops, sorry about that. https://github.com/llvm/llvm-project/pull/77147 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [Clang] Update Unicode version to 15.1 (PR #77147)

https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/77147 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix assertion failure when initializing union with FAM (PR #77298)

https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/77298 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix assertion failure when initializing union with FAM (PR #77298)

@@ -696,6 +696,9 @@ Bug Fixes in This Version - Clang now accepts recursive non-dependent calls to functions with deduced return type. Fixes (`#71015 `_) +- Fix assertion failure when initializing union containing struct

[clang] [clang] Fix assertion failure when initializing union with FAM (PR #77298)

https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/77298 >From 68e21b7604964b7b391d9a077ca52175af21b65a Mon Sep 17 00:00:00 2001 From: Nikita Popov Date: Mon, 8 Jan 2024 12:41:34 +0100 Subject: [PATCH 1/3] [clang] Fix assertion failure when initializing union with FAM

[clang] [clang] Fix assertion failure when initializing union with FAM (PR #77298)

https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/77298 >From 68e21b7604964b7b391d9a077ca52175af21b65a Mon Sep 17 00:00:00 2001 From: Nikita Popov Date: Mon, 8 Jan 2024 12:41:34 +0100 Subject: [PATCH 1/2] [clang] Fix assertion failure when initializing union with FAM

[clang] [clang] Fix assertion failure when initializing union with FAM (PR #77298)

https://github.com/nikic created https://github.com/llvm/llvm-project/pull/77298 When initializing a union that constrain a struct with a flexible array member, and the initializer list is empty, we currently trigger an assertion failure. This happens because getFlexibleArrayInitChars()

[clang] [OpenMP] Change `__tgt_device_image` to point to the image (PR #77003)

@@ -19,8 +19,8 @@ // OPENMP-COFF: @__start_omp_offloading_entries = hidden constant [0 x %struct.__tgt_offload_entry] zeroinitializer, section "omp_offloading_entries$OA" // OPENMP-COFF-NEXT: @__stop_omp_offloading_entries = hidden constant [0 x

[llvm] [clang] [RFC] Introducing `__builtin_consistent` to generate AArch64 BC.cond … (PR #72175)

nikic wrote: @davidbolvansky The semantics of this builtin are slightly different, see the discussion at https://discourse.llvm.org/t/rfc-consistent-branches-support-in-llvm/74889. But yes, the consensus is that adding this builtin is not worthwhile.

[lldb] [libc] [llvm] [clang] [mlir] [NFC][ObjectSizeOffset] Use classes instead of std::pair (PR #76882)

@@ -187,80 +187,124 @@ Value *lowerObjectSizeCall( const TargetLibraryInfo *TLI, AAResults *AA, bool MustSucceed, SmallVectorImpl *InsertedInstructions = nullptr); -using SizeOffsetType = std::pair; +/// SizeOffsetType - A base template class for the object size

[clang] [clang] Optimize castToDeclContext for 2% improvement in build times (PR #76825)

nikic wrote: https://llvm-compile-time-tracker.com/compare.php?from=98624914367bf9091919de330cf322fb6d5e468f=7d398e29b0180aacc646fed5406ad7fbd4b30c02=instructions%3Au Nice results for C++ code! https://github.com/llvm/llvm-project/pull/76825 ___

[llvm] [clang] [lld] [FuncAttrs] Deduce `noundef` attributes for return values (PR #76553)

nikic wrote: Yeah, we should skip this inference for functions with the sanitize_memory attribute. https://github.com/llvm/llvm-project/pull/76553 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[llvm] [clang] [lld] [FuncAttrs] Deduce `noundef` attributes for return values (PR #76553)

https://github.com/nikic approved this pull request. LGTM, assuming Linux CI passes now. https://github.com/llvm/llvm-project/pull/76553 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[llvm] [clang] [FuncAttrs] Deduce `noundef` attributes for return values (PR #76553)

@@ -1279,6 +1280,43 @@ static void addNonNullAttrs(const SCCNodeSet , } } +/// Deduce noundef attributes for the SCC. +static void addNoUndefAttrs(const SCCNodeSet , +SmallSet ) { + // Check each function in turn, determining which functions

[clang] [llvm] [FuncAttrs] Deduce `noundef` attributes for return values (PR #76553)

@@ -1279,6 +1280,43 @@ static void addNonNullAttrs(const SCCNodeSet , } } +/// Deduce noundef attributes for the SCC. +static void addNoUndefAttrs(const SCCNodeSet , +SmallSet ) { + // Check each function in turn, determining which functions

[llvm] [clang] [FuncAttrs] Deduce `noundef` attributes for return values (PR #76553)

@@ -27,7 +27,7 @@ #endif // function return types -// CHECK-LABEL: define dso_local <8 x half> @test_ret_v8f16( +// CHECK-LABEL: define dso_local noundef <8 x half> @test_ret_v8f16( nikic wrote: Ah, it seems to indeed be a "weird C rule":

[llvm] [clang] [FuncAttrs] Deduce `noundef` attributes for return values (PR #76553)

https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/76553 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [FuncAttrs] Deduce `noundef` attributes for return values (PR #76553)

@@ -27,7 +27,7 @@ #endif // function return types -// CHECK-LABEL: define dso_local <8 x half> @test_ret_v8f16( +// CHECK-LABEL: define dso_local noundef <8 x half> @test_ret_v8f16( nikic wrote: Do you know why clang places the noundef on the argument but

[llvm] [clang] [FuncAttrs] Deduce `noundef` attributes for return values (PR #76553)

nikic wrote: There are lld test failures. https://github.com/llvm/llvm-project/pull/76553 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [FuncAttrs] Infer `norecurse` for funcs with calls to `nocallback` callees (PR #76372)

https://github.com/nikic approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/76372 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [Clang][IR] add TBAA metadata on pointer, union and array types. (PR #75177)

nikic wrote: (As usual, please make any LLVM changes separately from Clang changes, especially if they affect IR design.) https://github.com/llvm/llvm-project/pull/75177 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[flang] [clang] [lldb] [clang-tools-extra] [compiler-rt] [libcxx] [llvm] [libc] [RegAllocFast] Refactor dominates algorithm for large basic block (PR #72250)

@@ -62,6 +62,107 @@ static RegisterRegAlloc fastRegAlloc("fast", "fast register allocator", namespace { +/// Assign ascending index for instructions in machine basic block. The index +/// can be used to determine dominance between instructions in same MBB. +class

[clang] [llvm] [IR] Fix GEP offset computations for vector GEPs (PR #75448)

https://github.com/nikic approved this pull request. LGTM I think this is a reasonable change in any case. https://github.com/llvm/llvm-project/pull/75448 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[llvm] [clang] [IR] Fix GEP offset computations for vector GEPs (PR #75448)

nikic wrote: > > Alternative would be to forbid GEP indexing into vectors entirely. > > I agree that it would be better if there just were no vector GEPs, but that > breaks importing older modules, and that cannot be easily auto-upgraded > (convert to byte-GEPs?). Yes, upgrade would be to

[llvm] [flang] [clang] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

nikic wrote: > > arrayidx > > We should teach `foldCmpLoadFromIndexedGlobal` to handle constant GEPs with > i8 source element type. There is a pending patch related to this: https://github.com/llvm/llvm-project/pull/67093 https://github.com/llvm/llvm-project/pull/68882

[clang] [flang] [llvm] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

nikic wrote: @dtcxzyw GitHub can't display the diff, and struggles to clone the repo. Can you share the diffs for just the mentioned files? https://github.com/llvm/llvm-project/pull/68882 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[llvm] [clang] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/68882 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/68882 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

@@ -560,14 +560,15 @@ define i32 @test28() nounwind { ; CHECK-NEXT: entry: ; CHECK-NEXT:[[ORIENTATIONS:%.*]] = alloca [1 x [1 x %struct.x]], align 8 ; CHECK-NEXT:[[T3:%.*]] = call i32 @puts(ptr noundef nonnull dereferenceable(1) @.str) #[[ATTR0]] +; CHECK-NEXT:

[clang] [llvm] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

https://github.com/nikic ready_for_review https://github.com/llvm/llvm-project/pull/68882 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/68882 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [SystemZ][z/OS] Add guard for dl_info and dladdr (PR #75637)

@@ -17,6 +17,7 @@ #include "clang/Driver/Driver.h" #include "llvm/ADT/STLExtras.h" #include "llvm/ADT/SmallString.h" +#include "llvm/Config/config.h" nikic wrote: This is a private LLVM header, see the comment at the top of the file. It cannot be included in

[clang] [AArch64][SME] Warn when using a streaming builtin from a non-streaming function (PR #75487)

nikic wrote: When building clang with clang, the regression on SemaChecking.cpp is now "only" 60% in terms of instructions retired (plus 0.4% during thin link, which is another ~50% in terms of SemaChecking). https://github.com/llvm/llvm-project/pull/75487

[clang] [clang][CGCUDANV] Unify PointerType members of CGNVCUDARuntime (NFC) (PR #75668)

https://github.com/nikic approved this pull request. LGTM There are already C-style function signatures in the comments, so I don't see value in keeping separate variable names. https://github.com/llvm/llvm-project/pull/75668 ___ cfe-commits mailing

[clang] [mlir] [llvm] [LLVM][IR] Replace ConstantInt's specialisation of getType() with getIntegerType(). (PR #75217)

https://github.com/nikic approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/75217 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [IR] Fix GEP offset computations for vector GEPs (PR #75448)

https://github.com/nikic commented: Looks fine to me. Alternative would be to forbid GEP indexing into vectors entirely. https://github.com/llvm/llvm-project/pull/75448 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [llvm] [IR] Fix GEP offset computations for vector GEPs (PR #75448)

@@ -111,6 +111,20 @@ define void @test_evaluate_gep_as_ptrs_array(ptr addrspace(2) %B) { ret void } +define void @test_overaligned_vec(i8 %B) { +; This should be turned into a constexpr instead of being an instruction +; CHECK-LABEL: @test_overaligned_vec( +;

[llvm] [clang] [IR] Fix GEP offset computations for vector GEPs (PR #75448)

@@ -108,7 +143,23 @@ class generic_gep_type_iterator { // that. bool isStruct() const { return isa(CurTy); } - bool isSequential() const { return isa(CurTy); } + bool isVector() const { return isa(CurTy); } + bool isSequential() const { return !isStruct(); } + + //

[llvm] [clang] [IR] Fix GEP offset computations for vector GEPs (PR #75448)

https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/75448 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][fatlto] Don't set ThinLTO module flag with FatLTO (PR #75079)

https://github.com/nikic approved this pull request. LGTM -- I think this change is clearly right, independently of the ModuleID issue. https://github.com/llvm/llvm-project/pull/75079 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [llvm] [LLVM][IR] Replace ConstantInt's specialisation of getType() with getIntegerType(). (PR #75217)

nikic wrote: > Most all the recommended changes assume the code paths will work equally well > for vector types as they do for scalar types. Can we be so sure this is the > case? This is why I opted to keep the casting assertions with the exception > of a few places where I could be sure the

[llvm] [clang] [LVI] Support using block values when handling conditions (PR #75311)

https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/75311 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [LVI] Support using block values when handling conditions (PR #75311)

https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/75311 >From 0b4f9e03bf84ffc0a24bc609879c96db9b1d2833 Mon Sep 17 00:00:00 2001 From: Nikita Popov Date: Tue, 12 Dec 2023 15:55:29 +0100 Subject: [PATCH 1/2] [LVI] Support using block values when handling conditions

[llvm] [clang] [ValueTracking] Add dominating condition support in computeKnownBits() (PR #73662)

nikic wrote: @eddyz87 Right, this is exactly the change I have been working on, see https://github.com/llvm/llvm-project/pull/75311. Unfortunately, it doesn't actually fix the BPF case, because that one involves a loop, and LVI is currently terrible at handling those. (Basically, even though

[clang] [llvm] [LLVM][IR] Replace ConstantInt's specialisation of getType() with getIntegerType(). (PR #75217)

@@ -6079,7 +6079,7 @@ static Value *simplifyRelativeLoad(Constant *Ptr, Constant *Offset, Type *Int32Ty = Type::getInt32Ty(Ptr->getContext()); auto *OffsetConstInt = dyn_cast(Offset); - if (!OffsetConstInt || OffsetConstInt->getType()->getBitWidth() > 64) + if

[llvm] [clang] [LLVM][IR] Replace ConstantInt's specialisation of getType() with getIntegerType(). (PR #75217)

@@ -1688,7 +1688,7 @@ void PolynomialMultiplyRecognize::setupPreSimplifier(Simplifier ) { if (I->getOpcode() != Instruction::Or) return nullptr; ConstantInt *Msb = dyn_cast(I->getOperand(1)); - if (!Msb || Msb->getZExtValue() !=

[llvm] [clang] [LLVM][IR] Replace ConstantInt's specialisation of getType() with getIntegerType(). (PR #75217)

@@ -673,8 +673,8 @@ void ConstantHoistingPass::findBaseConstants(GlobalVariable *BaseGV) { llvm::stable_sort(ConstCandVec, [](const ConstantCandidate , const ConstantCandidate ) { if (LHS.ConstInt->getType() !=

[clang] [llvm] [LLVM][IR] Replace ConstantInt's specialisation of getType() with getIntegerType(). (PR #75217)

@@ -1062,7 +1062,7 @@ void PolynomialMultiplyRecognize::promoteTo(Instruction *In, // Promote immediates. for (unsigned i = 0, n = In->getNumOperands(); i != n; ++i) { if (ConstantInt *CI = dyn_cast(In->getOperand(i))) - if (CI->getType()->getBitWidth() < DestBW)

[clang] [llvm] [LLVM][IR] Replace ConstantInt's specialisation of getType() with getIntegerType(). (PR #75217)

@@ -868,7 +868,7 @@ Constant *llvm::ConstantFoldBinaryInstruction(unsigned Opcode, Constant *C1, } if (GVAlign > 1) { -unsigned DstWidth = CI2->getType()->getBitWidth(); +unsigned DstWidth = CI2->getIntegerType()->getBitWidth();

[llvm] [clang] [LLVM][IR] Replace ConstantInt's specialisation of getType() with getIntegerType(). (PR #75217)

@@ -1577,7 +1577,7 @@ Value *PolynomialMultiplyRecognize::generate(BasicBlock::iterator At, static bool hasZeroSignBit(const Value *V) { if (const auto *CI = dyn_cast(V)) -return (CI->getType()->getSignBit() & CI->getSExtValue()) == 0; +return

[llvm] [clang] [ValueTracking] Add dominating condition support in computeKnownBits() (PR #73662)

nikic wrote: @yonghong-song I think it may be possible to improve CVP to handle this better, in which case we won't need BPF workarounds. I'll look into it. https://github.com/llvm/llvm-project/pull/73662 ___ cfe-commits mailing list

[clang] [llvm] [ValueTracking] Add dominating condition support in computeKnownBits() (PR #73662)

nikic wrote: @bjope It looks like the InstCombine changes enable IndVars to perform LFTR, which is unprofitable in this case. Though the `umax(1)` call is actually completely unnecessary here, but SCEV doesn't realize it. I've put up https://github.com/llvm/llvm-project/pull/75039 to fix

[clang] [llvm] [ValueTracking] Add dominating condition support in computeKnownBits() (PR #73662)

https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/73662 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[llvm] [clang] [ValueTracking] Add dominating condition support in computeKnownBits() (PR #73662)

nikic wrote: Okay, it looks like the mpeg2decode regression is indeed fixed. I think the only somewhat significant regression left is `Shootout-C++-ary2`, but in my IR diffs I don't see any regression there (only improvements with a bunch of conditions being optimized away).

[llvm] [clang] [LLVM][IR] Add native vector support to ConstantInt & ConstantFP. (PR #74502)

@@ -343,7 +343,7 @@ static bool verifyTripCount(Value *RHS, Loop *L, // If the RHS of the compare is equal to the backedge taken count we need // to add one to get the trip count. if (SCEVRHS == BackedgeTCExt || SCEVRHS == BackedgeTakenCount) { - ConstantInt

[clang] [llvm] [LLVM][IR] Add native vector support to ConstantInt & ConstantFP. (PR #74502)

@@ -343,7 +343,7 @@ static bool verifyTripCount(Value *RHS, Loop *L, // If the RHS of the compare is equal to the backedge taken count we need // to add one to get the trip count. if (SCEVRHS == BackedgeTCExt || SCEVRHS == BackedgeTakenCount) { - ConstantInt

[clang] [llvm] [LLVM][IR] Add native vector support to ConstantInt & ConstantFP. (PR #74502)

@@ -136,7 +144,11 @@ class ConstantInt final : public ConstantData { inline const APInt () const { return Val; } /// getBitWidth - Return the bitwidth of this constant. - unsigned getBitWidth() const { return Val.getBitWidth(); } + unsigned getBitWidth() const { +

[clang] [llvm] [LLVM][IR] Add native vector support to ConstantInt & ConstantFP. (PR #74502)

@@ -98,6 +99,13 @@ class ConstantInt final : public ConstantData { /// value. Otherwise return a ConstantInt for the given value. static Constant *get(Type *Ty, uint64_t V, bool IsSigned = false); + /// WARNING: Incomplete support, do not use. These methods exist for

[llvm] [clang] [LLVM][IR] Add native vector support to ConstantInt & ConstantFP. (PR #74502)

@@ -136,7 +144,11 @@ class ConstantInt final : public ConstantData { inline const APInt () const { return Val; } /// getBitWidth - Return the bitwidth of this constant. - unsigned getBitWidth() const { return Val.getBitWidth(); } + unsigned getBitWidth() const { +

[clang] [llvm] [LLVM][IR] Add native vector support to ConstantInt & ConstantFP. (PR #74502)

@@ -343,7 +343,7 @@ static bool verifyTripCount(Value *RHS, Loop *L, // If the RHS of the compare is equal to the backedge taken count we need // to add one to get the trip count. if (SCEVRHS == BackedgeTCExt || SCEVRHS == BackedgeTakenCount) { - ConstantInt

[clang] [llvm] [LLVM][IR] Add native vector support to ConstantInt & ConstantFP. (PR #74502)

@@ -98,6 +99,13 @@ class ConstantInt final : public ConstantData { /// value. Otherwise return a ConstantInt for the given value. static Constant *get(Type *Ty, uint64_t V, bool IsSigned = false); + /// WARNING: Incomplete support, do not use. These methods exist for

[clang] [llvm] [ValueTracking] Add dominating condition support in computeKnownBits() (PR #73662)

nikic wrote: Rebased over the SCEV change. @dtcxzyw Can you please give it another try? https://github.com/llvm/llvm-project/pull/73662 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

<    1   2   3   4   5   6   7   8   >