nikic wrote:
Okay, I managed to get access to a MacOS machine (turns out the GCC compile
farm has one!) and figured out what the problem is. Basically, the presence of
the constant expression meant that we previously always fell back to JIT and
now we use the IR interpreter instead, which fail
@@ -1444,6 +1445,8 @@ static AttrBuilder
IdentifyValidPoisonGeneratingAttributes(CallBase &CB) {
Valid.addAttribute(Attribute::NonNull);
if (CB.hasRetAttr(Attribute::Alignment))
Valid.addAlignmentAttr(CB.getRetAlign());
+ if (CB.hasRetAttr(Attribute::Range))
+Va
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/92666
___
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/92666
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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&to=4feae05c6abda364a9295aecfa600d7d4e7dfeb6&stat=instructions:u
> > While that's nice, it does s
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/92666
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Nikita Popov
Date: 2024-05-29T16:39:21+02:00
New Revision: 975477e7f7ee1d8c29975224abb452f73b90db36
URL:
https://github.com/llvm/llvm-project/commit/975477e7f7ee1d8c29975224abb452f73b90db36
DIFF:
https://github.com/llvm/llvm-project/commit/975477e7f7ee1d8c29975224abb452f73b90db36.diff
https://github.com/nikic created https://github.com/llvm/llvm-project/pull/93697
The data-layout independent constant folding currently has some rather gnarly
code for canonicalizing GEP indices to reduce "notional overindexing", and then
infers inbounds based on that canonicalization.
Now tha
nikic wrote:
@aeubanks Following up on this comment:
https://github.com/llvm/llvm-project/pull/89872#discussion_r1578582193 After
looking into this a bit, I do think we can drop this and make things a good bit
simpler :)
https://github.com/llvm/llvm-project/pull/93697
https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/93697
>From 8a6462df3f329aa939db4c8bff87bd57bb0d6445 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Tue, 28 May 2024 13:47:05 +0200
Subject: [PATCH 1/2] [ConstantFold] Remove notional over-indexing fold
The data-layou
https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/93697
>From 8a6462df3f329aa939db4c8bff87bd57bb0d6445 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Tue, 28 May 2024 13:47:05 +0200
Subject: [PATCH 1/3] [ConstantFold] Remove notional over-indexing fold
The data-layou
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/93697
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
This change seems to have some compile-time overhead. I'm not seeing a lot on
CTMark, but during the clang bootstrap there are many files with ~1%
regressions
(http://llvm-compile-time-tracker.com/compare_clang.php?from=ec8fe598a94d2826f8e4f79367a5a45a6b32d284&to=9c4a716c1292096fc
Author: Nikita Popov
Date: 2024-05-30T10:24:57+02:00
New Revision: cd9a02e2c76ec2f37409c6f7becd61e605c117d8
URL:
https://github.com/llvm/llvm-project/commit/cd9a02e2c76ec2f37409c6f7becd61e605c117d8
DIFF:
https://github.com/llvm/llvm-project/commit/cd9a02e2c76ec2f37409c6f7becd61e605c117d8.diff
Author: Nikita Popov
Date: 2024-05-30T11:47:07+02:00
New Revision: b2bd024384b484647da9fd9863bf6f77b5731949
URL:
https://github.com/llvm/llvm-project/commit/b2bd024384b484647da9fd9863bf6f77b5731949
DIFF:
https://github.com/llvm/llvm-project/commit/b2bd024384b484647da9fd9863bf6f77b5731949.diff
https://github.com/nikic created https://github.com/llvm/llvm-project/pull/93823
This fold is subtly incorrect, because DL-unaware constant folding does not
know the correct index type to use, and just performs the addition in the type
that happens to already be there. This is incorrect, since
nikic wrote:
> > because the DL-aware constant folding will take care of this anyway.
>
> Can you point out where we do this fold?
https://github.com/llvm/llvm-project/blob/1f46729a18ef13c3ba4184ead1da4ab3037cb7ae/llvm/lib/Analysis/ConstantFolding.cpp#L865
> > I've only kept the straightforwar
nikic wrote:
These Sema refactorings have been increasing the time to build clang by a small
increment with every patch -- this one is an extra large jump of 0.7%
(https://llvm-compile-time-tracker.com/compare.php?from=59e2a6b08f3e40afea87da3838ba69e1e15b6672&to=8aa80199751b0cd6631d057b0bfb2158
https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/93823
>From 7fbc0366638de3262294c1923a1b45aa6338fe8f Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 30 May 2024 09:57:21 +0200
Subject: [PATCH 1/2] [ConstantFold] Remove non-trivial gep-of-gep fold
This fold is s
Author: Nikita Popov
Date: 2024-05-31T08:55:59+02:00
New Revision: 63dc31b68b78bc0e5deef21b98cab72de997c471
URL:
https://github.com/llvm/llvm-project/commit/63dc31b68b78bc0e5deef21b98cab72de997c471
DIFF:
https://github.com/llvm/llvm-project/commit/63dc31b68b78bc0e5deef21b98cab72de997c471.diff
nikic wrote:
> I wonder if compile-time regressions come from new translation units I add,
> because they definitely include stuff.
Yes, I believe that is the primary contributor. You can see the per-file
breakdown here:
https://llvm-compile-time-tracker.com/compare_clang.php?from=59e2a6b08f3
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/93823
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Nikita Popov
Date: 2024-05-31T10:37:32+02:00
New Revision: 51e459a561519c8d51e2b4cadddc0d1f99c8b7ef
URL:
https://github.com/llvm/llvm-project/commit/51e459a561519c8d51e2b4cadddc0d1f99c8b7ef
DIFF:
https://github.com/llvm/llvm-project/commit/51e459a561519c8d51e2b4cadddc0d1f99c8b7ef.diff
nikic wrote:
ping
https://github.com/llvm/llvm-project/pull/93454
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
@mikaelholmen Thanks for the report, should be fixed by
https://github.com/llvm/llvm-project/commit/bda8d1ad72fc72f21f6c536692594376d00db8b6.
https://github.com/llvm/llvm-project/pull/92885
___
cfe-commits mailing list
cfe-commits@lists.l
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
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
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
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:
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
nikic wrote:
19.x has already branched, so it's fine to land this now (for LLVM 20).
https://github.com/llvm/llvm-project/pull/98505
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic commented:
I think this is missing some test coverage for the `!align` values. Right now
it just includes test updates, and I don't think the actual value is checked
anywhere.
https://github.com/llvm/llvm-project/pull/98746
_
https://github.com/nikic commented:
Some nits, no strong opinion on overall approach.
https://github.com/llvm/llvm-project/pull/99439
___
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/99439
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -12,12 +12,33 @@
//===--===//
#include "llvm/Transforms/Instrumentation.h"
+#include "llvm/IR/DiagnosticInfo.h"
#include "llvm/IR/IntrinsicInst.h"
#include "llvm/IR/Module.h"
#include "llvm/TargetParser
@@ -19,6 +19,7 @@
#include "llvm/IR/Function.h"
#include "llvm/IR/IRBuilder.h"
#include "llvm/IR/Instruction.h"
+#include "llvm/IR/Module.h"
nikic wrote:
Should be a forward-declare.
https://github.com/llvm/llvm-project/pull/99439
@@ -12,12 +12,33 @@
//===--===//
#include "llvm/Transforms/Instrumentation.h"
+#include "llvm/IR/DiagnosticInfo.h"
#include "llvm/IR/IntrinsicInst.h"
#include "llvm/IR/Module.h"
#include "llvm/TargetParser
nikic wrote:
This causes significant compile-time regressions, especially for unoptimized
builds:
https://llvm-compile-time-tracker.com/compare.php?from=39b6900852e7a1187bd742ba5c1387ca1be58e2c&to=2acf77f987331c05520c5bfd849326909ffce983&stat=instructions:u
You probably need to separately matc
nikic wrote:
The pipeline test changes here still look problematic. Can you make the
ObjCARCContract pass preserve the DT?
https://github.com/llvm/llvm-project/pull/101114
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
nikic wrote:
I can see the argument for dereferenceable_or_null, but I don't see any way in
which range will be useful.
https://github.com/llvm/llvm-project/pull/91101
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
nikic wrote:
Thanks for following up on this!
For the record, this was the final result:
https://llvm-compile-time-tracker.com/compare.php?from=18cdfa72e046a40d4372ee98602fd1a65a94&to=0bb68b55715487447ffceaa1ab59f7a0bc8c7979&stat=instructions:u
https://github.com/llvm/llvm-project/pull/968
https://github.com/nikic created https://github.com/llvm/llvm-project/pull/99620
We already infer this in IPSCCP, but as that pass runs very early, it cannot
make use of simplifications (in particular post-inline simplifications).
This fixes most cases from https://github.com/llvm/llvm-project/
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/99620
___
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/99620
>From 23bdf84091020df916441b3ed2d2cc74f4059e37 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 19 Jul 2024 11:02:56 +0200
Subject: [PATCH] [CVP] Infer range return attribute
We already infer this in IPSCCP,
@@ -2799,9 +2799,37 @@ CodeGenFunction::EmitLoadOfReference(LValue RefLVal,
llvm::LoadInst *Load =
Builder.CreateLoad(RefLVal.getAddress(), RefLVal.isVolatile());
CGM.DecorateInstructionWithTBAA(Load, RefLVal.getTBAAInfo());
- return makeNaturalAddressForPointer(Load
nikic wrote:
CTMark is not compiled with `-Wextra`, so we'd not get any useful data out of
this patch. What changes does one have to do to enable `-Wimplicit-fallthrough`
by default (not just for `-Wextra`)?
https://github.com/llvm/llvm-project/pull/97926
__
nikic wrote:
https://github.com/llvm/llvm-project/pull/78114 should absolutely not go onto
the release branch -- and with that in mind, please hold off on merging this PR
until LLVM 19 has branched as well.
https://github.com/llvm/llvm-project/pull/98745
___
nikic wrote:
@DeinAlptraum It's a major change to the clang python bindings. In general,
please refrain from landing major changes immediately before branching (and
certainly do not backport them to the release branch).
https://github.com/llvm/llvm-project/pull/98745
__
@@ -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
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 bo
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
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
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
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
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
@@ -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
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
nikic wrote:
Just as a FYI this inference introduces a small amount of overhead:
http://llvm-compile-time-tracker.com/compare.php?from=866bec7d3ff8803b68e9972939c1a76ccf5fdc62&to=902b2a26ab9e1e78dfb66b52fba4512c91472e09&stat=instructions:u
https://github.com/llvm/llvm-project/pull/103716
__
nikic wrote:
@mikaelholmen Thanks for the reproducer, this makes the issue clear. BasicAA is
incorrectly returning NoAlias for the pointers due to
https://github.com/llvm/llvm-project/pull/98608.
The issue is that the `add` gets decomposed, but we preserve the nuw flag,
effectively making it
nikic wrote:
I don't think we need to revert it. Without this patch it's mostly harmless.
I've been working on a fix for this issue. I think we need to track NUW through
LinearExpression using something along these lines:
https://gist.github.com/nikic/d6986bb62539bba048ced15dd497a4fb
https://
https://github.com/nikic requested changes to this pull request.
I'm very confused. `readonly` means that the memory behind `this` cannot be
changed, not that the pointer cannot be changed.
https://github.com/llvm/llvm-project/pull/106499
___
cfe-comm
nikic wrote:
> > I'm very confused. `readonly` means that the memory behind `this` cannot be
> > changed, not that the pointer cannot be changed.
>
> Out of curiosity, it looks not same in https://llvm.org/docs/LangRef.html:
>
> > This attribute indicates that the function does not write throu
https://github.com/nikic commented:
I think the general direction is fine here. I would suggest to split this up
into three parts: 1. Add noext attribute and disabled verification, 2. fix any
verification failures (e.g. by emitting noext), 3. enable verification.
It would be good to still be a
nikic wrote:
> Patch updated per @nikic suggestion to use a TargetOption flag to simply
> disable this for llc.
>
> With all the llc lit tests out of the way, I now see:
>
> * 1 test failing in CodeGenObjC
>
> * failing tests in clang/test/Interpreter
>
> * failing tetss in llvm/test/E
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/106732
>From 50efbbd59ed639d9604f3b13faf1fb8be60161e7 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 30 Aug 2024 12:46:53 +0200
Subject: [PATCH 1/2] [SCCP] Infer return attributes in SCCP as well
We can infer th
nikic wrote:
> Compilation time impact looks acceptable. If you want to further reduce
> compile-time impact, you can remove/stop inferring unnecessary range
> attributes on intrinsic calls (e.g., `call i32 range(i32 0, -2147483648)
> @llvm.abs(i32 %x)`). These trivial cases are already handle
@@ -354,6 +354,36 @@ bool SCCPSolver::removeNonFeasibleEdges(BasicBlock *BB,
DomTreeUpdater &DTU,
return true;
}
+void SCCPSolver::inferReturnAttributes() const {
+ for (const auto &I : getTrackedRetVals()) {
+Function *F = I.first;
+const ValueLatticeElement &Retu
@@ -354,6 +354,36 @@ bool SCCPSolver::removeNonFeasibleEdges(BasicBlock *BB,
DomTreeUpdater &DTU,
return true;
}
+void SCCPSolver::inferReturnAttributes() const {
+ for (const auto &I : getTrackedRetVals()) {
+Function *F = I.first;
+const ValueLatticeElement &Retu
nikic wrote:
It looks like this causes a compile-time regression. The clang thin link time
increases by 1%
(https://llvm-compile-time-tracker.com/compare_clang.php?from=9ccf82543d509bb5a0f5d0551fc4d6c1913b9a9b&to=5c0d61e318a77434487fcec8361d8110fb06e59d&stat=instructions%3Au).
There is no regr
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/106732
>From 50efbbd59ed639d9604f3b13faf1fb8be60161e7 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 30 Aug 2024 12:46:53 +0200
Subject: [PATCH 1/3] [SCCP] Infer return attributes in SCCP as well
We can infer th
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/106732
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -35,6 +35,7 @@ typedef unsigned long long uint64_t;
// CHECK: while.cond.i:
// CHECK-NEXT:[[__TAGP_ADDR_0_I:%.*]] = phi ptr [ [[P:%.*]], [[ENTRY:%.*]]
], [ [[__TAGP_ADDR_1_I:%.*]], [[CLEANUP_I:%.*]] ]
// CHECK-NEXT:[[__R_0_I:%.*]] = phi i64 [ 0, [[ENTRY]] ], [
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/107040
___
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/98026
>From e5c0cba0f065a8efab6c8a91d436f1309478 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Mon, 8 Jul 2024 15:02:31 +0200
Subject: [PATCH 1/2] [SCCP] Add support for vectors
Add preliminary support for vector
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/98026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -20,16 +20,15 @@ using namespace llvm;
int main(int argc, char **argv) {
#if defined(__i386__) || defined(_M_IX86) || \
defined(__x86_64__) || defined(_M_X64)
- StringMap features;
-
- if (!sys::getHostCPUFeatures(features))
+ const < StringMap features = sys::getHost
@@ -32,7 +32,9 @@
#include "llvm/ADT/StringRef.h"
#include "llvm/ADT/StringSet.h"
#include "llvm/Frontend/OpenMP/OMPGridValues.h"
+#include "llvm/IR/Attributes.h"
#include "llvm/IR/DerivedTypes.h"
+#include "llvm/IR/Function.h"
nikic wrote:
Could you please m
https://github.com/nikic approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/98329
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
> in some build config `TargetInfo.cpp` is built without dependency to
> `LLVM-Core`.
Okay, that means that putting this code inside Basic/ is a layering violation.
You need to move it into CodeGen/. Probably best to revert the whole change in
the meantime.
https://github.com/ll
@@ -133,7 +133,7 @@ class AArch64TargetCodeGenInfo : public TargetCodeGenInfo {
}
}
auto *Fn = cast(GV);
-BPI.setFnAttributes(*Fn);
+CGM.getTargetCodeGenInfo().setFnAttributes(BPI, *Fn);
nikic wrote:
```suggestion
setFnAttributes(BPI,
@@ -413,6 +414,12 @@ class TargetCodeGenInfo {
return nullptr;
}
+ void setFnAttributes(const TargetInfo::BranchProtectionInfo &BPI,
nikic wrote:
```suggestion
void setBranchProtectionFnAttributes(const TargetInfo::BranchProtectionInfo
&BPI,
```
Or
nikic wrote:
> Okay, so x86_64 describes it in byte terms and says they're little-endian,
> which is consistent with the overall target. Interestingly, it does not
> guarantee the content of the excess bits. The code-generation in this patch
> is consistent with that: the extension we do is un
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/98611
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -230,8 +230,13 @@ void DwarfFDECache::iterateCacheEntries(void (*func)(
}
#endif // defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND)
-
-#define arrayoffsetof(type, index, field) ((size_t)(&((type *)0)[index].field))
+template
+__attribute__((no_sanitize("undefined"))) static inlin
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
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
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
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
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
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
@@ -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
-
@@ -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 = getelemen
@@ -1699,8 +1701,12 @@ Expected
BitcodeReader::materializeValue(unsigned StartValID,
I = GetElementPtrInst::Create(BC->SrcElemTy, Ops[0],
ArrayRef(Ops).drop_front(), "constexpr",
InsertBB);
-
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
https://lists.llvm.org/cgi-bin/mailman/lis
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, I
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
---
llvm/docs/LangRef
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
---
llvm/docs/LangRef
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
nikic wrote:
Reverted in
https://github.com/llvm/llvm-project/commit/fa750f09be6966de7423ddce1af7d1eaf817182c
due to large compile-time regressions in some cases, see
https://llvm-compile-time-tracker.com/compare.php?from=9bbefb7f600019c9d7025281132dd160729bfff2&to=03c53c69a367008da689f0d2940e
601 - 700 of 1388 matches
Mail list logo
