[clang] [llvm] [IR] Add getelementptr nusw and nuw flags (PR #90824)

@@ -11295,27 +11297,46 @@ memory though, even if it happens to point into allocated storage. See the :ref:`Pointer Aliasing Rules ` section for more information. -If the ``inbounds`` keyword is present, the result value of a -``getelementptr`` with any non-zero indices is a -

[clang] [llvm] [IR] Add getelementptr nusw and nuw flags (PR #90824)

https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/90824 >From eb27a1b94ec807323d204b51d5c01cc22056e1c7 Mon Sep 17 00:00:00 2001 From: Nikita Popov Date: Thu, 2 May 2024 12:11:18 +0900 Subject: [PATCH 1/4] Add support for getelementptr nusw and nuw --- llvm/docs/LangRef

[clang] [llvm] [IR] Add getelementptr nusw and nuw flags (PR #90824)

nikic wrote: > Are the TODOs encompassing all the cases? Why we don't want to set the flags > in `PHITransAddr` as well? No, the TODOs are only for places where I had to modify code, but the used implementation is obviously non-optimal to minimize initial impact. There are many more places th

[clang] [llvm] [IR] Add getelementptr nusw and nuw flags (PR #90824)

https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/90824 >From eb27a1b94ec807323d204b51d5c01cc22056e1c7 Mon Sep 17 00:00:00 2001 From: Nikita Popov Date: Thu, 2 May 2024 12:11:18 +0900 Subject: [PATCH 1/2] Add support for getelementptr nusw and nuw --- llvm/docs/LangRef

[clang] [llvm] [IR] Add getelementptr nusw and nuw flags (PR #90824)

https://github.com/nikic created https://github.com/llvm/llvm-project/pull/90824 This implements the `nusw` and `nuw` flags for `getelementptr` as proposed at https://discourse.llvm.org/t/rfc-add-nusw-and-nuw-flags-for-getelementptr/78672. There are a bunch of places annotated with `TODO(gep_no

[clang] [llvm] [InstCombine] Canonicalize scalable GEPs to use llvm.vscale intrinsic (PR #90569)

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

[clang] [llvm] [InstCombine] Canonicalize scalable GEPs to use llvm.vscale intrinsic (PR #90569)

nikic wrote: > I gave this a test and _almost_ nothing changed. So looks good in that regard. I expect that the main producer of scalable GEPs is LoopVectorize, which will already use the llvm.vscale representation anyway. So there's probably not many `https://github.com/llvm/llvm-project/pull

[clang] [compiler-rt] [llvm] [ConstantFolding] Canonicalize constexpr GEPs to i8 (PR #89872)

nikic wrote: > btw we're still looking into a performance regression caused by #68882 that > still repros with LLVM head, even after the SROA enhancements. this patch > looks good, but can we hold off a bit on submitting this? Sure! https://github.com/llvm/llvm-project/pull/89872

[clang] [compiler-rt] [llvm] [ConstantFolding] Canonicalize constexpr GEPs to i8 (PR #89872)

@@ -944,43 +943,18 @@ Constant *SymbolicallyEvaluateGEP(const GEPOperator *GEP, return ConstantExpr::getIntToPtr(C, ResTy); } - // Otherwise form a regular getelementptr. Recompute the indices so that - // we eliminate over-indexing of the notional static type array bo

[clang] [llvm] [SCCP] Swap out range metadata to range attribute (PR #90134)

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

[clang] [llvm] [SCCP] Swap out range metadata to range attribute (PR #90134)

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

[clang] [Driver] Don't default to -mrelax-all for non-RISCV -O0 (PR #90013)

nikic wrote: FYI I'm seeing about 0.6% compile-time regressions for `O0` test-suite builds with this change (https://llvm-compile-time-tracker.com/compare.php?from=ef2ca97f48f1aee1483f0c29de5ba52979bec454&to=18376810f359dbd39d2a0aa0ddfc0f7f50eac199&stat=instructions:u). Though there is also a

[clang] [clang-tools-extra] [Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base clas

nikic wrote: FYI this change has some visible compile-time impact, with some 0.5-1% regressions on various LLVM files (https://llvm-compile-time-tracker.com/compare_clang.php?from=2f2e31c3c980407b2660b4f5d10e7cdb3fa79138&to=a8fd0d029dca7d17eee72d0445223c2fe1ee7758&stat=instructions%3Au&sortBy=i

[clang] [llvm] [ConstantFolding] Canonicalize constexpr GEPs to i8 (PR #89872)

nikic wrote: > Hi @nikic I read this RFC > https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699 > and it seems it reqires multiple patches to implement it. I am wondering if > you have a link or page which contains all related PRs (or future PRs) ? I > want to track its

[clang] [llvm] [ConstantFolding] Canonicalize constexpr GEPs to i8 (PR #89872)

@@ -944,43 +943,18 @@ Constant *SymbolicallyEvaluateGEP(const GEPOperator *GEP, return ConstantExpr::getIntToPtr(C, ResTy); } - // Otherwise form a regular getelementptr. Recompute the indices so that - // we eliminate over-indexing of the notional static type array bo

[clang] [llvm] [InstCombine] Swap out range metadata to range attribute for cttz/ctlz/ctpop (PR #88776)

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

[clang] [llvm] [ConstantFolding] Canonicalize constexpr GEPs to i8 (PR #89872)

@@ -944,43 +943,18 @@ Constant *SymbolicallyEvaluateGEP(const GEPOperator *GEP, return ConstantExpr::getIntToPtr(C, ResTy); } - // Otherwise form a regular getelementptr. Recompute the indices so that - // we eliminate over-indexing of the notional static type array bo

[clang] [llvm] [mlir] Fix warning about mismatches between function parameter and call-site args names (PR #89294)

nikic wrote: Isn't the warning about a mismatch between declaration and definition, not call args? The InstCombine change does make the definition and declaration match. On Fri, Apr 19, 2024, at 17:07, Mehdi Amini wrote: > > > ***@***. commented on this pull request. > > > In llvm/lib/T

[clang] [llvm] [mlir] Fix Definition Mismatches (PR #89294)

https://github.com/nikic commented: InstCombine change looks good. https://github.com/llvm/llvm-project/pull/89294 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Move several vector intrinsics out of experimental namespace (PR #88748)

nikic wrote: > > I don't know what the policy is for promoting intrinsics from experimental > > to first-class or if it's documented anywhere (?), but I would expect this > > to be accompanied with an RFC / announcement on Discourse. > > I don't remember any intrinsic ever making the move out

[clang] Improve stack usage to increase recursive initialization depth (PR #88546)

nikic wrote: This change seems to cause significant compile-time regressions for C++ code (https://llvm-compile-time-tracker.com/compare.php?from=184ba038ac1d444980b3e554b0057f3f30c516ab&to=4082a7554521572a65a5a0008c4661a534df659d&stat=instructions%3Au). Probably most damning are the times for

[clang] [llvm] [ValueTracking] Restore isKnownNonZero parameter order. (PR #88873)

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

[clang] [llvm] [ValueTracking] Convert `isKnownNonZero` to use SimplifyQuery (PR #85863)

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

[clang] [llvm] [InstCombine] Infer nsw/nuw for trunc (PR #87910)

@@ -897,7 +897,20 @@ Instruction *InstCombinerImpl::visitTrunc(TruncInst &Trunc) { } } - return nullptr; + bool Changed = false; + if (!Trunc.hasNoSignedWrap() && + ComputeMaxSignificantBits(Src, /*Depth=*/0, &Trunc) <= DestWidth) { +Trunc.setHasNoSignedWrap

[clang] [llvm] [InstCombine] Infer nsw/nuw for trunc (PR #87910)

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

[clang] [llvm] [InstCombine] Infer nsw/nuw for trunc (PR #87910)

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

[clang] [llvm] [InstCombine] Add canonicalization of `sitofp` -> `uitofp nneg` (PR #88299)

nikic wrote: > > Can the implementation of foldFBinOpOfIntCastsFromSign be simplified to use > > nneg instead of KnownBits after this change? > > yeah we could. Should I do a survey of existing folds first to ensure we > don't incorrectly keep flags (like with `trunc nuw/nsw`) before integrati

[clang] [llvm] [InstCombine] Add canonicalization of `sitofp` -> `uitofp nneg` (PR #88299)

nikic wrote: Can the implementation of foldFBinOpOfIntCastsFromSign be simplified to use nneg instead of KnownBits after this change? https://github.com/llvm/llvm-project/pull/88299 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists

[clang] [llvm] [InstCombine] Add canonicalization of `sitofp` -> `uitofp nneg` (PR #88299)

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

[clang] [llvm] [InstCombine][CVP][SCCP] Add support for `uitofp nneg` (PR #86154)

nikic wrote: Can you please split this into separate patches? Or at least split out the InstCombine part of it? https://github.com/llvm/llvm-project/pull/86154 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mail

[clang] [llvm] [InstCombine] Infer nsw/nuw for trunc (PR #87910)

@@ -897,7 +897,20 @@ Instruction *InstCombinerImpl::visitTrunc(TruncInst &Trunc) { } } - return nullptr; + bool Changed = false; + if (!Trunc.hasNoSignedWrap() && + ComputeMaxSignificantBits(Src, /*Depth=*/0, &Trunc) <= DestWidth) { +Trunc.setHasNoSignedWrap

[clang] [llvm] [InstCombine] Infer nsw/nuw for trunc (PR #87910)

@@ -897,7 +897,20 @@ Instruction *InstCombinerImpl::visitTrunc(TruncInst &Trunc) { } } - return nullptr; + bool Changed = false; + if (!Trunc.hasNoSignedWrap() && + ComputeMaxSignificantBits(Src, /*Depth=*/0, &Trunc) <= DestWidth) { +Trunc.setHasNoSignedWrap

[clang] 3eb8063 - [CodeGen] Fix test on 32-bit targets (NFC)

Author: Nikita Popov Date: 2024-03-20T14:20:44+01:00 New Revision: 3eb806373e3164b242db65f8c900e4adb5a2eddf URL: https://github.com/llvm/llvm-project/commit/3eb806373e3164b242db65f8c900e4adb5a2eddf DIFF: https://github.com/llvm/llvm-project/commit/3eb806373e3164b242db65f8c900e4adb5a2eddf.diff

[clang] [lld] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

nikic wrote: @dtcxzyw Auto-upgrade is only for bitcode files, we usually do not upgrade IR files. Can you regenerate the inputs with the new clang version? https://github.com/llvm/llvm-project/pull/84341 ___ cfe-commits mailing list cfe-commits@lists.

[clang] [lld] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

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

[clang] [lld] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

@@ -47,28 +47,66 @@ static bool splitGlobal(GlobalVariable &GV) { if (!Init) return false; - // Verify that each user of the global is an inrange getelementptr constant. - // From this it follows that any loads from or stores to that global must use - // a pointer der

[clang] [lld] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

@@ -23,24 +23,26 @@ @PR23753_b = global ptr getelementptr (i8, ptr @PR23753_a, i64 ptrtoint (ptr @PR23753_a to i64)) ; CHECK: @PR23753_b = global ptr getelementptr (i8, ptr @PR23753_a, i64 ptrtoint (ptr @PR23753_a to i64)) -; Verify that inrange on an index inhibits over-ind

[clang] Sanitizer: Support -fwrapv with -fsanitize=signed-integer-overflow (PR #82432)

nikic wrote: > > Shouldn't plain `-fsanitize=undefined` disable this sanitizer by default > > (requiring explicit opt-in)? In `-fwrapv` mode this is not undefined > > behavior, so `-fsanitize=undefined` should not complain about it. > > I was on the fence whether `-fsanitize=undefined` should

[clang] [clang][CodeGen] Allow memcpy replace with trivial auto var init (PR #84230)

nikic wrote: @antoniofrighetto You need to update the PR description, not the commit message. https://github.com/llvm/llvm-project/pull/84230 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co

[clang] [llvm] [InstCombine] Canonicalize `(sitofp x)` -> `(uitofp x)` if `x >= 0` (PR #82404)

nikic wrote: I don't think we really have a strong motivation for this change beyond "having a canonical form is usually good", so if it's causing issues for some targets, then probably just not doing it is fine. But if we do want to keep it, then yeah, this would be a reasonable motivation fo

[clang] [llvm] [InstCombine] Canonicalize `(sitofp x)` -> `(uitofp x)` if `x >= 0` (PR #82404)

nikic wrote: @goldsteinn Doesn't seem worthwhile. https://github.com/llvm/llvm-project/pull/82404 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [InstCombine] Canonicalize `(sitofp x)` -> `(uitofp x)` if `x >= 0` (PR #82404)

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

[clang] [lld] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

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

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

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

[clang] [clang][CodeGen] Allow memcpy replace with trivial auto var init (PR #84230)

nikic wrote: This change also "fixes" https://github.com/llvm/llvm-project/issues/78034 in the sense that we return to the clang 17 status quo of the emitted IR being wrong but mostly working out in practice. https://github.com/llvm/llvm-project/pull/84230 _

[clang] Sanitizer: Support -fwrapv with -fsanitize=signed-integer-overflow (PR #82432)

nikic wrote: Shouldn't plain `-fsanitize=undefined` disable this sanitizer by default (requiring explicit opt-in)? In `-fwrapv` mode this is not undefined behavior, so `-fsanitize=undefined` should not complain about it. https://github.com/llvm/llvm-project/pull/82432

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

nikic wrote: So yeah, I think the source-relative representation is better if we consider only the current vtable / GlobalSplit use case (where we'd just convert result-relative to source-relative anyway), while the result-relative representation is better if we consider a potential extension

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

nikic wrote: > And then want to restrict inrange to the inner array, then for the > source-relative case we can write: > > ``` > %p1 = ptradd ptr %base, i32 %outer_idx * 44 > %p2 = ptradd ptr inrange(0, 40) %p1, i32 %inner_idx * 4 > ``` > > While the result-relative case can't represent this wi

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

nikic wrote: > Have you thought about the implications for dynamic (non-constant) indices? inrange is only supported on constant expressions, and I think the consensus is that it should not be extended to non-constant cases. In that case, we would represent the information independently of the

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

nikic wrote: @aeubanks @preames @nhaehnle Before I finish up this PR (need to update more tests and fix GlobalSplit), I'd like to have some feedback on one point. I'm currently proposing the `inrange` attribute to be relative to the result pointer, so ``` getelementptr inbounds inrange(-16, 16

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

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

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

https://github.com/nikic created https://github.com/llvm/llvm-project/pull/84341 As part of the [migration to ptradd](https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699), we need to change the representation of the `inrange` attribute, which is used for vtable splitting

[clang] Revert "[clang] Avoid memcopy for small structure with padding under … (PR #84230)

nikic wrote: Can you please provide more information on what the regression was / how this fixes it? https://github.com/llvm/llvm-project/pull/84230 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinf

[clang] [clang] Remove unused lambda capture. (PR #83550)

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

[clang] [APINotes] Upstream Sema logic to apply API Notes to decls (PR #78445)

nikic wrote: FYI this change adds some overhead (about 0.2% for O0) builds (http://llvm-compile-time-tracker.com/compare.php?from=046682ef88a254443e8620bfd48b35bfa0a83809&to=440b1743ee0c8bfb7bf0c4b503bde5ab9af88dc0&stat=instructions:u). Is it possible to avoid it for people not using API notes?

[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 -vector-library=ArmP

[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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

[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">, Visibility<[ClangOpti

[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 d

[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 /// s

[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 https://lists.llvm.org/cgi-bin/mailman/lis

[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 InstCo

[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 https://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 firs

[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 th

[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: ht

[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 https://lists.llvm.org/cgi-bin/mailman/list

[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 KEYWORD_

[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 macr

[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&to=f582b874c35e2b90046da8e8c30a7fa30ba08167&stat=instructions:u (They are mildly positive now, and there are some text size reductions.) https://gith

[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 l

[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 - -f

[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 - -f

[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 whether

[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 wi

[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 W

[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 W

[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() assumes

<    1   2   3   4   5   6   7   8   9   >