https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/90824
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/90824
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/90824
>From ff4658cf7661003d940452251147ee58315c774c Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 2 May 2024 12:11:18 +0900
Subject: [PATCH 1/7] Add support for getelementptr nusw and nuw
---
https://github.com/nikic created https://github.com/llvm/llvm-project/pull/93454
add_clang_library() will create a library clangFoo that depends on objlib
obj.clangFoo. Then clang_target_link_libraries() will add a clang-cpp
dependency to clangFoo, but obj.clangFoo will instead get
@@ -31,6 +31,10 @@
; CHECK-NEXT: AArch64 Stack Tagging
; CHECK-NEXT: SME ABI Pass
; CHECK-NEXT: Exception handling preparation
+; CHECK-NEXT: Dominator Tree Construction
+; CHECK-NEXT: Basic Alias Analysis (stateless AA impl)
+; CHECK-NEXT:
nikic wrote:
Reverted due to major compile-time regressions for unoptimized builds, see
https://llvm-compile-time-tracker.com/compare.php?from=910292c3ac2ebe43cdbc90223c6c9702128316db=8cc8e5d6c6ac9bfc888f3449f7e424678deae8c2=instructions:u.
https://github.com/llvm/llvm-project/pull/92331
Author: Nikita Popov
Date: 2024-05-24T08:14:26+02:00
New Revision: 1579e9ca9ce17364963861517fecf13b00fe4d8a
URL:
https://github.com/llvm/llvm-project/commit/1579e9ca9ce17364963861517fecf13b00fe4d8a
DIFF:
https://github.com/llvm/llvm-project/commit/1579e9ca9ce17364963861517fecf13b00fe4d8a.diff
nikic wrote:
FYI this causes a minor compile-time improvement in stage1 builds using gcc:
https://llvm-compile-time-tracker.com/compare.php?from=32c3561d44aa792ef08d72b5a4c342c9965bc4c2=4feae05c6abda364a9295aecfa600d7d4e7dfeb6=instructions:u
While that's nice, it does suggest that the flags
nikic wrote:
Unfortunately this is a Darwin-only test, and I don't have access to any MacOS
systems.
@JDevlieghere Could you please help me debug this issue? The test fails when
trying to evaluate this expression:
nikic wrote:
There's already another approval from @aeubanks, so I plan to merge this next
Monday if there's no more feedback.
https://github.com/llvm/llvm-project/pull/90824
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
nikic wrote:
@antmox Already fixed in
https://github.com/llvm/llvm-project/commit/c609c04e32ef43f63a6ee54025fadf649c3247cc.
https://github.com/llvm/llvm-project/pull/92885
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
Author: Nikita Popov
Date: 2024-05-22T08:37:09+02:00
New Revision: c609c04e32ef43f63a6ee54025fadf649c3247cc
URL:
https://github.com/llvm/llvm-project/commit/c609c04e32ef43f63a6ee54025fadf649c3247cc
DIFF:
https://github.com/llvm/llvm-project/commit/c609c04e32ef43f63a6ee54025fadf649c3247cc.diff
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/92885
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -8,7 +8,8 @@
// CHECK: entry:
// CHECK-NEXT: %retval = alloca i32
// CHECK-NEXT: store i32 0, ptr %retval
-// CHECK-NEXT: [[ZEXT:%.*]] = zext i1 true to i32
+// CHECK-NEXT: [[CMP:%.*]] = icmp ne ptr @b, @a
+// CHECK-NEXT: [[ZEXT:%.*]] = zext i1 [[CMP]] to i32
@@ -1422,7 +1417,7 @@ define i1 @user_of_not_called() {
; CHECK-LABEL: define {{[^@]+}}@user_of_not_called() {
; CHECK-NEXT:call void @useFnDecl(ptr addrspace(42) noundef nonnull
addrspacecast (ptr @not_called1 to ptr addrspace(42)))
; CHECK-NEXT:call void
@@ -43,9 +43,9 @@
; CHECK: @mul = global ptr null
; CHECK: @xor = global ptr @A
; CHECK: @B = external global %Ty
-; CHECK: @icmp_ult1 = global i1 icmp ugt (ptr getelementptr inbounds (i64, ptr
@A, i64 1), ptr @A)
+; CHECK: @icmp_ult1 = global i1 icmp ult (ptr @A, ptr
https://github.com/nikic created https://github.com/llvm/llvm-project/pull/92885
Do not create icmp/fcmp constant expressions in IRBuilder etc anymore, i.e.
treat them as "undesirable". This is in preparation for removing them entirely.
Part of:
https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/90824
>From b74cc982c95f7750a581e93bc0f246786c69ef3d Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 2 May 2024 12:11:18 +0900
Subject: [PATCH 1/7] Add support for getelementptr nusw and nuw
---
nikic wrote:
@MaskRay Thanks! That does fix the regression.
https://github.com/llvm/llvm-project/pull/91082
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/89872
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
@MaskRay It looks like the new version still causes large compile-time
regressions for sqlite3 debug builds:
http://llvm-compile-time-tracker.com/compare.php?from=7529fe2e92e79eef22a528a7168e4dd777d6e9bd=9500a5d02e23f9b43294e5f662ac099f8989c0e4=instructions:u
It's smaller than
@@ -0,0 +1,93 @@
+//===-- llvm/GEPNoWrapFlags.h - NoWrap flags for GEPs ---*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier:
nikic wrote:
Reverted in
https://github.com/llvm/llvm-project/commit/fa750f09be6966de7423ddce1af7d1eaf817182c
due to large compile-time regressions in some cases, see
Author: Nikita Popov
Date: 2024-05-16T09:56:07+09:00
New Revision: fa750f09be6966de7423ddce1af7d1eaf817182c
URL:
https://github.com/llvm/llvm-project/commit/fa750f09be6966de7423ddce1af7d1eaf817182c
DIFF:
https://github.com/llvm/llvm-project/commit/fa750f09be6966de7423ddce1af7d1eaf817182c.diff
https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/90824
>From 009ffa45c131982caac5b9025678cde0418ac003 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 2 May 2024 12:11:18 +0900
Subject: [PATCH 1/7] Add support for getelementptr nusw and nuw
---
https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/90824
>From 009ffa45c131982caac5b9025678cde0418ac003 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 2 May 2024 12:11:18 +0900
Subject: [PATCH 1/5] Add support for getelementptr nusw and nuw
---
nikic wrote:
@sgundapa Hm, I think the problem may be that while
https://github.com/llvm/llvm-project/pull/90802 removes the limitation on the
element types, it's still limited to single-index GEPs, while here there are
multiple indices. (Assuming this is related to swapping the GEPs at all,
nikic wrote:
@sgundapa Does https://github.com/llvm/llvm-project/pull/90802 fix the issue
you're seeing?
https://github.com/llvm/llvm-project/pull/68882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -1699,8 +1701,12 @@ Expected
BitcodeReader::materializeValue(unsigned StartValID,
I = GetElementPtrInst::Create(BC->SrcElemTy, Ops[0],
ArrayRef(Ops).drop_front(), "constexpr",
InsertBB);
-
@@ -316,3 +316,82 @@ define <2 x i32> @test_trunc_both_reversed_vector(<2 x
i64> %a) {
%res = trunc nsw nuw <2 x i64> %a to <2 x i32>
ret <2 x i32> %res
}
+
+define ptr @gep_nuw(ptr %p, i64 %idx) {
+; CHECK: %gep = getelementptr nuw i8, ptr %p, i64 %idx
+ %gep =
@@ -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
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
---
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
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
---
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
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
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
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
@@ -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
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
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
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=18376810f359dbd39d2a0aa0ddfc0f7f50eac199=instructions:u).
Though there is also a 4.5%
nikic wrote:
FYI this change has some visible compile-time impact, with some 0.5-1%
regressions on various LLVM files
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
@@ -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
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
@@ -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
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
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
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
nikic wrote:
This change seems to cause significant compile-time regressions for C++ code
(https://llvm-compile-time-tracker.com/compare.php?from=184ba038ac1d444980b3e554b0057f3f30c516ab=4082a7554521572a65a5a0008c4661a534df659d=instructions%3Au).
Probably most damning are the times for the
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
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
@@ -897,7 +897,20 @@ Instruction *InstCombinerImpl::visitTrunc(TruncInst
) {
}
}
- return nullptr;
+ bool Changed = false;
+ if (!Trunc.hasNoSignedWrap() &&
+ ComputeMaxSignificantBits(Src, /*Depth=*/0, ) <= DestWidth) {
+Trunc.setHasNoSignedWrap(true);
+
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
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
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
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://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
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
@@ -897,7 +897,20 @@ Instruction *InstCombinerImpl::visitTrunc(TruncInst
) {
}
}
- return nullptr;
+ bool Changed = false;
+ if (!Trunc.hasNoSignedWrap() &&
+ ComputeMaxSignificantBits(Src, /*Depth=*/0, ) <= DestWidth) {
+Trunc.setHasNoSignedWrap(true);
+
@@ -897,7 +897,20 @@ Instruction *InstCombinerImpl::visitTrunc(TruncInst
) {
}
}
- return nullptr;
+ bool Changed = false;
+ if (!Trunc.hasNoSignedWrap() &&
+ ComputeMaxSignificantBits(Src, /*Depth=*/0, ) <= DestWidth) {
+Trunc.setHasNoSignedWrap(true);
+
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
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
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
@@ -47,28 +47,66 @@ static bool splitGlobal(GlobalVariable ) {
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
@@ -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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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://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
nikic wrote:
FYI this change adds some overhead (about 0.2% for O0) builds
(http://llvm-compile-time-tracker.com/compare.php?from=046682ef88a254443e8620bfd48b35bfa0a83809=440b1743ee0c8bfb7bf0c4b503bde5ab9af88dc0=instructions:u).
Is it possible to avoid it for people not using API notes?
@@ -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
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://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
@@ -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">,
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
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
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
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
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
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
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
///
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://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
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
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
1 - 100 of 605 matches
Mail list logo
