[clang] Reland "[clang] Add nuw attribute to GEPs (#105496)" (PR #107257)

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

[clang] Reland "[clang] Add nuw attribute to GEPs (#105496)" (PR #107257)

hazzlim wrote: Nice - CI seems happy, so I plan to land this later today if no objections. https://github.com/llvm/llvm-project/pull/107257 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm

[clang] [clang] Emit nuw GEPs for array subscript expressions (PR #103088)

hazzlim wrote: > Can this be closed in favor of #105496? Yes good point - will close this and open a PR to Reland #105496. https://github.com/llvm/llvm-project/pull/103088 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/

[clang] [clang] Emit nuw GEPs for array subscript expressions (PR #103088)

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

[clang] [clang] Add nuw attribute to GEPs (PR #105496)

hazzlim wrote: > @mikaelholmen Thanks for the reproducer, this makes the issue clear. BasicAA > is incorrectly returning NoAlias for the pointers due to #98608. > > The issue is that the `add` gets decomposed, but we preserve the nuw flag, > effectively making it an `add nuw i16 n, -1`. Thank

[clang] Revert "[clang] Add nuw attribute to GEPs" (PR #106343)

hazzlim wrote: > Please let me know if you have a fix for that. I'll land revert in the > morning by PDT. Thank you for flagging this up and opening this @vitalybuka - I'm taking a look now to see if there's an easy enough fix to save reverting. https://github.com/llvm/llvm-project/pull/10634

[clang] [clang] Add nuw attribute to GEPs (PR #105496)

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

[clang] [clang] Add nuw attribute to GEPs (PR #105496)

hazzlim wrote: I plan to land this patch later today, unless there are any objections / further comments. Thanks for reviewing @nikic @efriedma-quic https://github.com/llvm/llvm-project/pull/105496 ___ cfe-commits mailing list cfe-commits@lists.llvm

[clang] [clang] Emit nuw GEPs for array subscript expressions (PR #103088)

hazzlim wrote: > > adding nuw is also valid for signed indices here > > I don't understand how you think this would work; a-1 and a+-1 are required > to produce the same result. The thinking here RE signed indices was that in this special case, where the base address of the GEP is the start o

[clang] [clang] Add nuw attribute to GEPs (PR #105496)

@@ -7,13 +7,6 @@ struct X { int a[2]; }; extern int bar(); -//. -// CHECK: @test.i23 = internal global i32 4, align 4 -// CHECK: @i = global i32 4, align 4 -// CHECK: @Arr = global [100 x i32] zeroinitializer, align 16 -// CHECK: @foo2.X = internal global ptr getelementptr (i8

[clang] [clang] Emit nuw GEPs for array subscript expressions (PR #103088)

hazzlim wrote: This seems correct from my reading of the relevant parts of the C/C++ standard, regarding pointer arithmetic and array subscript expressions. It does actually seem like the restriction to unsigned indices here is actually unnecessary, and adding `nuw` is also valid for signed in

[clang] [clang] Emit nuw GEPs for array subscript expressions (PR #103088)

https://github.com/hazzlim created https://github.com/llvm/llvm-project/pull/103088 Generate nuw GEPs for array subscript expressions where the base address points to the base of a constant size array and the index is unsigned. >From 1eca1fe3d73c9832bde3e09a93f8d0a2a2bb3698 Mon Sep 17 00:00:00

[clang] [llvm] [mlir] [polly] [clang] Generate nuw GEPs for struct member accesses (PR #99538)

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

[clang] [llvm] [clang] Generate nuw GEPs for struct member accesses (PR #99538)

@@ -1902,16 +1902,18 @@ class IRBuilderBase { } Value *CreateConstGEP2_32(Type *Ty, Value *Ptr, unsigned Idx0, unsigned Idx1, -const Twine &Name = "") { +const Twine &Name = "", +GEPNoWrapF

[clang] [clang] Generate nuw GEPs for struct member accesses (PR #99538)

hazzlim wrote: > > `CGBuilder` is just aiming to provide an `Address` overload of LLVM's > > `CreateStructGEP`. It seems wrong for two overloads to have subtly > > different behavior. > > Is there a reason why LLVM's `CreateStructGEP` doesn't add `nuw` itself? > > Good point - I can see that i

[clang] [clang] Generate nuw GEPs for struct member accesses (PR #99538)

hazzlim wrote: > `CGBuilder` is just aiming to provide an `Address` overload of LLVM's > `CreateStructGEP`. It seems wrong for two overloads to have subtly different > behavior. > > Is there a reason why LLVM's `CreateStructGEP` doesn't add `nuw` itself? Good point - I can see that it makes m

[clang] [clang] Generate nuw GEPs for struct member accesses (PR #99538)

hazzlim wrote: This seemed like the right place to make the change - please let me know if not! I've not restricted this to a subset of languages because it seems fairly unambiguous that nuw holds for these inbounds struct member accesses, but it could be limited to e.g. C/C++ if that is more