[clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)

[Nikita Popov via 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=4feae05c6abda364a9295aecfa600d7d4e7dfeb6=instructions:u
 While that's nice, it does suggest that the flags are not the same as before.

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

[clang] [llvm] [IR] Avoid creating icmp/fcmp constant expressions (PR #92885)

[Nikita Popov via cfe-commits]

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: 
https://github.com/llvm/llvm-project/blob/58ddf3a0c6b6bbdf682ef3421d05e846a6e00527/lldb/test/API/commands/expression/weak_symbols/TestWeakSymbols.py#L37-L42

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

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

[Nikita Popov via cfe-commits]

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

[clang] [llvm] [IR] Avoid creating icmp/fcmp constant expressions (PR #92885)

[Nikita Popov via cfe-commits]

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

[clang] c609c04 - [CodeGen] Use fixed triple in weak-external test (NFC)

[Nikita Popov via cfe-commits]

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

LOG: [CodeGen] Use fixed triple in weak-external test (NFC)

The codegen here differs substantially if UseARMMethodPtrABI is
enabled. Use a fixed x86 triple to avoid this.

Added: 


Modified: 
clang/test/CodeGenCXX/weak-external.cpp

Removed: 




diff  --git a/clang/test/CodeGenCXX/weak-external.cpp 
b/clang/test/CodeGenCXX/weak-external.cpp
index 587fba36a0ada..02f05bfa7e1ee 100644
--- a/clang/test/CodeGenCXX/weak-external.cpp
+++ b/clang/test/CodeGenCXX/weak-external.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -triple %itanium_abi_triple 
%s -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -triple 
x86_64-unknown-linux-gnu %s -emit-llvm -o - | FileCheck %s
 // PR4262
 
 // CHECK-NOT: _ZNSs12_S_constructIPKcEEPcT_S3_RKSaIcESt20forward_iterator_tag



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [IR] Avoid creating icmp/fcmp constant expressions (PR #92885)

[Nikita Popov via cfe-commits]

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

[clang] [llvm] [IR] Avoid creating icmp/fcmp constant expressions (PR #92885)

[Nikita Popov via 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

nikic wrote:

I remember looking into this test a while ago (the `zext i1 true` is pretty 
weird, usually IRBuilder would fold that away) and the context is that one of 
the values here gets RAUWed and that would enable the folding. For constant 
expressions, replacing an operand will also re-fold the expression. For 
instructions, this doesn't happen. In any case, it will get folded later if 
optimizations are enabled.

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

[clang] [llvm] [IR] Avoid creating icmp/fcmp constant expressions (PR #92885)

[Nikita Popov via cfe-commits]

@@ -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 @useFnDef(ptr addrspace(42) noundef nonnull 
addrspacecast (ptr @not_called2 to ptr addrspace(42)))
-; CHECK-NEXT:ret i1 icmp eq (ptr addrspace(42) addrspacecast (ptr 
@not_called3 to ptr addrspace(42)), ptr addrspace(42) null)
+; CHECK-NEXT:ret i1 false

nikic wrote:

This change looked suspicious to me -- I was afraid that we started to simplify 
a null comparison through an addrspace cast, which wouldn't generally be valid. 
But this doesn't seem to be the case as far as ConstantFolding/InstSimplify are 
concerned. This is some Attributor-specific behavior and it has been flipping 
back and forth in this test in multiple previous changes. Maybe @jdoerfert 
knows what is happening here.

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

[clang] [llvm] [IR] Avoid creating icmp/fcmp constant expressions (PR #92885)

[Nikita Popov via cfe-commits]

@@ -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 getelementptr inbounds 
(i64, ptr @A, i64 1))

nikic wrote:

There are a few cases like this where we don't canonicalize constant 
expressions involving icmp anymore. This is because we also refuse to create 
new icmp expressions even if we already had one originally.

This is fine because it only happens if there was an icmp const expr in the 
first place, which will be removed shortly after this lands.

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

[clang] [llvm] [IR] Avoid creating icmp/fcmp constant expressions (PR #92885)

[Nikita Popov via cfe-commits]

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://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179

>From 27f6437864f34aec80ac9fe43d45da6bebcb4765 Mon Sep 17 00:00:00 2001
From: Nikita Popov 
Date: Tue, 21 May 2024 09:40:26 +0200
Subject: [PATCH] [IR] Avoid creating icmp/fcmp constant expressions

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://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179
---
 clang/test/Analysis/builtin_signbit.cpp   |  36 +++---
 .../catch-nullptr-and-nonzero-offset.c|  62 +++
 clang/test/CodeGen/constantexpr-fneg.c|   3 +-
 clang/test/CodeGenCXX/cxx11-thread-local.cpp  |  20 ++--
 .../test/CodeGenCXX/ubsan-nullability-arg.cpp |   3 +-
 clang/test/CodeGenCXX/weak-external.cpp   |  15 ++-
 clang/test/Driver/linker-wrapper-image.c  |  98 +
 clang/test/OpenMP/threadprivate_codegen.cpp   | 104 ++
 llvm/include/llvm/Analysis/TargetFolder.h |   2 +-
 llvm/include/llvm/IR/ConstantFolder.h |   2 +-
 llvm/lib/Analysis/ConstantFolding.cpp |   2 +-
 llvm/lib/IR/ConstantFold.cpp  |  13 ++-
 llvm/test/Assembler/ConstantExprFold.ll   |   4 +-
 llvm/test/Assembler/ConstantExprNoFold.ll |   4 +-
 llvm/test/Assembler/vector-cmp.ll |   2 +-
 .../AMDGPU/lower-ctor-dtor-constexpr-alias.ll |   3 +-
 llvm/test/CodeGen/AMDGPU/lower-ctor-dtor.ll   |   3 +-
 .../AMDGPU/lower-multiple-ctor-dtor.ll|   3 +-
 .../MemorySanitizer/check-constant-shadow.ll  |   3 +-
 .../SanitizerBinaryMetadata/atomics.ll|  12 +-
 .../Transforms/Attributor/value-simplify.ll   |   7 +-
 .../binop-select-cast-of-select-cond.ll   |   2 +-
 .../constant-fold-address-space-pointer.ll|   6 +-
 .../Transforms/InstCombine/getelementptr.ll   |   3 +-
 ...hoist-xor-by-constant-from-xor-by-value.ll |   3 +-
 llvm/test/Transforms/InstCombine/pr33453.ll   |   2 +-
 llvm/test/Transforms/InstCombine/pr83947.ll   |   4 +-
 llvm/test/Transforms/InstCombine/rem.ll   |   4 +-
 .../Transforms/InstCombine/select-and-or.ll   |   4 +-
 .../InstCombine/select-safe-transforms.ll |   4 +-
 .../InstSimplify/ConstProp/bitcast.ll |   9 +-
 .../InstSimplify/ConstProp/icmp-global.ll |  54 ++---
 .../InstSimplify/bitcast-vector-fold.ll   |   3 +-
 llvm/test/Transforms/InstSimplify/compare.ll  |   6 +-
 .../Transforms/InstSimplify/past-the-end.ll   |   6 +-
 .../JumpThreading/constant-fold-status.ll |   3 +-
 .../LowerTypeTests/cfi-direct-call1.ll|  10 +-
 .../LowerTypeTests/function-weak.ll   |  74 +++--
 .../test/Transforms/SCCP/conditions-ranges.ll |   9 +-
 .../phi-to-select-constexpr-icmp.ll   |   2 +-
 40 files changed, 353 insertions(+), 256 deletions(-)

diff --git a/clang/test/Analysis/builtin_signbit.cpp 
b/clang/test/Analysis/builtin_signbit.cpp
index 57e6816ce2802..be10f0950f69b 100644
--- a/clang/test/Analysis/builtin_signbit.cpp
+++ b/clang/test/Analysis/builtin_signbit.cpp
@@ -84,28 +84,30 @@ long double ld = -1.0L;
 // CHECK-LE-LABEL: define dso_local void @_Z12test_signbitv(
 // CHECK-LE-SAME: ) #[[ATTR0:[0-9]+]] {
 // CHECK-LE-NEXT:  entry:
-// CHECK-LE-NEXT:[[FROMBOOL:%.*]] = zext i1 icmp slt (i64 trunc (i128 
bitcast (ppc_fp128 0xM3FF0 to i128) to i64), i64 0) 
to i8
+// CHECK-LE-NEXT:[[TMP0:%.*]] = icmp slt i64 trunc (i128 bitcast 
(ppc_fp128 0xM3FF0 to i128) to i64), 0
+// CHECK-LE-NEXT:[[FROMBOOL:%.*]] = zext i1 [[TMP0]] to i8
 // CHECK-LE-NEXT:store i8 [[FROMBOOL]], ptr @b, align 1
-// CHECK-LE-NEXT:[[TMP0:%.*]] = load ppc_fp128, ptr @ld, align 16
-// CHECK-LE-NEXT:[[TMP1:%.*]] = bitcast ppc_fp128 [[TMP0]] to i128
-// CHECK-LE-NEXT:[[TMP2:%.*]] = trunc i128 [[TMP1]] to i64
-// CHECK-LE-NEXT:[[TMP3:%.*]] = icmp slt i64 [[TMP2]], 0
-// CHECK-LE-NEXT:[[FROMBOOL1:%.*]] = zext i1 [[TMP3]] to i8
+// CHECK-LE-NEXT:[[TMP1:%.*]] = load ppc_fp128, ptr @ld, align 16
+// CHECK-LE-NEXT:[[TMP2:%.*]] = bitcast ppc_fp128 [[TMP1]] to i128
+// CHECK-LE-NEXT:[[TMP3:%.*]] = trunc i128 [[TMP2]] to i64
+// CHECK-LE-NEXT:[[TMP4:%.*]] = icmp slt i64 [[TMP3]], 0
+// CHECK-LE-NEXT:[[FROMBOOL1:%.*]] = zext i1 [[TMP4]] to i8
 // CHECK-LE-NEXT:store i8 [[FROMBOOL1]], ptr @b, align 1
 // CHECK-LE-NEXT:store i8 0, ptr @b, align 1
-// CHECK-LE-NEXT:[[TMP4:%.*]] = load double, ptr @d, align 8
-// CHECK-LE-NEXT:[[CONV:%.*]] = fptrunc double [[TMP4]] to float
-// CHECK-LE-NEXT:[[TMP5:%.*]] = bitcast float [[CONV]] to i32
-// CHECK-LE-NEXT:[[TMP6:%.*]] = icmp slt i32 [[TMP5]], 

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

[Nikita Popov via cfe-commits]

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

---
 llvm/docs/LangRef.rst | 57 --
 llvm/docs/ReleaseNotes.rst|  1 +
 llvm/include/llvm/AsmParser/LLToken.h |  1 +
 llvm/include/llvm/Bitcode/LLVMBitCodes.h  |  8 +++
 llvm/include/llvm/IR/Instructions.h   | 14 +
 llvm/include/llvm/IR/Operator.h   | 26 +++-
 llvm/lib/AsmParser/LLLexer.cpp|  1 +
 llvm/lib/AsmParser/LLParser.cpp   | 21 ++-
 llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 20 +--
 llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | 11 +++-
 llvm/lib/IR/AsmWriter.cpp |  4 ++
 llvm/lib/IR/Instruction.cpp   | 22 +--
 llvm/lib/IR/Instructions.cpp  | 16 +
 llvm/lib/IR/Operator.cpp  |  3 +-
 .../Scalar/SeparateConstOffsetFromGEP.cpp |  8 +++
 .../Transforms/Utils/FunctionComparator.cpp   |  6 ++
 llvm/lib/Transforms/Vectorize/VPlan.h |  5 ++
 llvm/test/Assembler/flags.ll  | 43 +
 llvm/test/Transforms/InstCombine/freeze.ll| 22 +++
 llvm/test/Transforms/SimplifyCFG/HoistCode.ll | 60 +++
 llvm/test/tools/llvm-reduce/reduce-flags.ll   | 18 --
 .../deltas/ReduceInstructionFlags.cpp |  4 ++
 22 files changed, 333 insertions(+), 38 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 358eb4b867925..74097343a444d 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -11184,6 +11184,8 @@ Syntax:
 
= getelementptr , ptr {,  }*
= getelementptr inbounds , ptr {,  }*
+   = getelementptr nusw , ptr {,  }*
+   = getelementptr nuw , ptr {,  }*
= getelementptr inrange(S,E) , ptr {,  }*
= getelementptr ,  ,  

 
@@ -11299,27 +11301,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
-:ref:`poison value ` if one of the following rules is violated:
-
-*  The base pointer has an *in bounds* address of an allocated object, which
+The ``getelementptr`` instruction may have a number of attributes that impose
+additional rules. If any of the rules are violated, the result value is a
+:ref:`poison value `. In cases where the base is a vector of
+pointers, the attributes apply to each computation element-wise.
+
+For ``nusw`` (no unsigned signed wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the signed value
+   (``trunc nsw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in a signed sense (``mul nsw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in a signed sense (``add nsw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, interpreted as
+   a signed number, does not wrap the index type.
+
+For ``nuw`` (no unsigned wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the unsigned value
+   (``trunc nuw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in an unsigned sense (``mul nuw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in an unsigned sense (``add nuw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, also interpreted as
+   an unsigned number, does not wrap the index type (``add nuw``).
+
+For ``inbounds`` all rules of the ``nusw`` attribute apply. Additionally,
+if the ``getelementptr`` has any non-zero indices, the following rules apply:
+
+ * The base pointer has an *in bounds* address of an allocated object, which
means that it points into an allocated object, or to its end. Note that the
object does not have to be live anymore; being in-bounds of a deallocated
object is sufficient.
-*  If the type of an index is larger than the pointer index type, the
-   truncation to the pointer index type preserves the signed value.
-*  The multiplication of an index by the type size does not wrap the pointer
-   index type in a signed sense (``nsw``).
-*  The successive addition of each offset (without adding the base address) 
does
-   not wrap the pointer index type in a signed sense 

[clang] [llvm] [MC] Make UseAssemblerInfoForParsing mostly true (PR #91082)

[Nikita Popov via cfe-commits]

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

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

[Nikita Popov via 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

[clang] [llvm] [MC] Make UseAssemblerInfoForParsing mostly true (PR #91082)

[Nikita Popov via 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 before (2% instead of 4%) but still there.

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

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

[Nikita Popov via cfe-commits]

@@ -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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines the nowrap flags for getelementptr operators.
+//
+//===--===//
+
+#ifndef LLVM_IR_GEPNOWRAPFLAGS_H
+#define LLVM_IR_GEPNOWRAPFLAGS_H
+
+namespace llvm {
+
+/// Represents flags for the getelementptr instruction/expression.
+/// The following flags are supported:
+///  * inbounds (implies nusw)
+///  * nusw (no unsigned signed wrap)
+///  * nuw (no unsigned wrap)
+/// See LangRef for a description of their semantics.
+class GEPNoWrapFlags {
+  enum : unsigned {
+InBoundsFlag = (1 << 0),
+NUSWFlag = (1 << 1),
+NUWFlag = (1 << 2),
+  };
+
+  unsigned Flags;
+  GEPNoWrapFlags(unsigned Flags) : Flags(Flags) {
+assert((!isInBounds() || hasNoUnsignedSignedWrap()) &&
+   "inbounds implies nusw");
+  }
+
+public:
+  GEPNoWrapFlags() : Flags(0) {}
+  // For historical reasons, interpret plain boolean as InBounds.
+  // TODO: Migrate users to pass explicit GEPNoWrapFlags and remove this ctor.
+  GEPNoWrapFlags(bool IsInBounds)

nikic wrote:

This is a backwards-compatiblity ctor because we're replacing existing `bool 
IsInBounds` parameters with `GEPNoWrapFlags NW` instead. As the TODO indicates, 
this ctor will be removed in the future. It avoids having to touch large 
amounts of code in this PR in sub-optimal ways.

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

[clang] [llvm] [MC] Remove UseAssemblerInfoForParsing (PR #91082)

[Nikita Popov via cfe-commits]

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=03c53c69a367008da689f0d2940e2197eb4a955c=instructions:u.
 sqlite3 regresses by 5% in unoptimized builds.

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

[clang] fa750f0 - Revert "[MC] Remove UseAssemblerInfoForParsing"

[Nikita Popov via cfe-commits]

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

LOG: Revert "[MC] Remove UseAssemblerInfoForParsing"

This reverts commit 03c53c69a367008da689f0d2940e2197eb4a955c.

This causes very large compile-time regressions in some cases,
e.g. sqlite3 at O0 regresses by 5%.

Added: 


Modified: 
clang/tools/driver/cc1as_main.cpp
llvm/include/llvm/MC/MCStreamer.h
llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
llvm/lib/MC/MCObjectStreamer.cpp
llvm/lib/MC/MCStreamer.cpp
llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp
llvm/lib/Target/SPIRV/SPIRVAsmPrinter.cpp
llvm/test/MC/AsmParser/assembler-expressions-inlineasm.ll
llvm/tools/llvm-mc/llvm-mc.cpp
llvm/tools/llvm-ml/llvm-ml.cpp

Removed: 




diff  --git a/clang/tools/driver/cc1as_main.cpp 
b/clang/tools/driver/cc1as_main.cpp
index 4eb753a7297a9..86afe22fac24c 100644
--- a/clang/tools/driver/cc1as_main.cpp
+++ b/clang/tools/driver/cc1as_main.cpp
@@ -576,6 +576,9 @@ static bool ExecuteAssemblerImpl(AssemblerInvocation ,
 Str.get()->emitZeros(1);
   }
 
+  // Assembly to object compilation should leverage assembly info.
+  Str->setUseAssemblerInfoForParsing(true);
+
   bool Failed = false;
 
   std::unique_ptr Parser(

diff  --git a/llvm/include/llvm/MC/MCStreamer.h 
b/llvm/include/llvm/MC/MCStreamer.h
index 50986e6bde886..69867620e1bf8 100644
--- a/llvm/include/llvm/MC/MCStreamer.h
+++ b/llvm/include/llvm/MC/MCStreamer.h
@@ -245,6 +245,8 @@ class MCStreamer {
   /// requires.
   unsigned NextWinCFIID = 0;
 
+  bool UseAssemblerInfoForParsing;
+
   /// Is the assembler allowed to insert padding automatically?  For
   /// correctness reasons, we sometimes need to ensure instructions aren't
   /// separated in unexpected ways.  At the moment, this feature is only
@@ -294,10 +296,11 @@ class MCStreamer {
 
   MCContext () const { return Context; }
 
-  // MCObjectStreamer has an MCAssembler and allows more expression folding at
-  // parse time.
   virtual MCAssembler *getAssemblerPtr() { return nullptr; }
 
+  void setUseAssemblerInfoForParsing(bool v) { UseAssemblerInfoForParsing = v; 
}
+  bool getUseAssemblerInfoForParsing() { return UseAssemblerInfoForParsing; }
+
   MCTargetStreamer *getTargetStreamer() {
 return TargetStreamer.get();
   }

diff  --git a/llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp 
b/llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
index 08e3c208ba4d3..d0ef3e5a19391 100644
--- a/llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
+++ b/llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
@@ -102,6 +102,9 @@ void AsmPrinter::emitInlineAsm(StringRef Str, const 
MCSubtargetInfo ,
   std::unique_ptr Parser(
   createMCAsmParser(SrcMgr, OutContext, *OutStreamer, *MAI, BufNum));
 
+  // Do not use assembler-level information for parsing inline assembly.
+  OutStreamer->setUseAssemblerInfoForParsing(false);
+
   // We create a new MCInstrInfo here since we might be at the module level
   // and not have a MachineFunction to initialize the TargetInstrInfo from and
   // we only need MCInstrInfo for asm parsing. We create one unconditionally

diff  --git a/llvm/lib/MC/MCObjectStreamer.cpp 
b/llvm/lib/MC/MCObjectStreamer.cpp
index a9003a164b306..d2da5d0d3f90f 100644
--- a/llvm/lib/MC/MCObjectStreamer.cpp
+++ b/llvm/lib/MC/MCObjectStreamer.cpp
@@ -40,7 +40,14 @@ MCObjectStreamer::MCObjectStreamer(MCContext ,
 
 MCObjectStreamer::~MCObjectStreamer() = default;
 
-MCAssembler *MCObjectStreamer::getAssemblerPtr() { return Assembler.get(); }
+// AssemblerPtr is used for evaluation of expressions and causes
+// 
diff erence between asm and object outputs. Return nullptr to in
+// inline asm mode to limit divergence to assembly inputs.
+MCAssembler *MCObjectStreamer::getAssemblerPtr() {
+  if (getUseAssemblerInfoForParsing())
+return Assembler.get();
+  return nullptr;
+}
 
 void MCObjectStreamer::addPendingLabel(MCSymbol* S) {
   MCSection *CurSection = getCurrentSectionOnly();

diff  --git a/llvm/lib/MC/MCStreamer.cpp b/llvm/lib/MC/MCStreamer.cpp
index 199d865ea3496..176d55aa890be 100644
--- a/llvm/lib/MC/MCStreamer.cpp
+++ b/llvm/lib/MC/MCStreamer.cpp
@@ -93,7 +93,7 @@ void MCTargetStreamer::emitAssignment(MCSymbol *Symbol, const 
MCExpr *Value) {}
 
 MCStreamer::MCStreamer(MCContext )
 : Context(Ctx), CurrentWinFrameInfo(nullptr),
-  CurrentProcWinFrameInfoStartIndex(0) {
+  CurrentProcWinFrameInfoStartIndex(0), UseAssemblerInfoForParsing(false) {
   SectionStack.push_back(std::pair());
 }
 

diff  --git a/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp 
b/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp
index bd48a5f80c828..b7388ed9e85a8 100644
--- 

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

[Nikita Popov via cfe-commits]

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.rst | 57 --
 llvm/docs/ReleaseNotes.rst|  1 +
 llvm/include/llvm/AsmParser/LLToken.h |  1 +
 llvm/include/llvm/Bitcode/LLVMBitCodes.h  |  8 +++
 llvm/include/llvm/IR/Instructions.h   | 14 +
 llvm/include/llvm/IR/Operator.h   | 26 +++-
 llvm/lib/AsmParser/LLLexer.cpp|  1 +
 llvm/lib/AsmParser/LLParser.cpp   | 21 ++-
 llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 20 +--
 llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | 11 +++-
 llvm/lib/IR/AsmWriter.cpp |  4 ++
 llvm/lib/IR/Instruction.cpp   | 22 +--
 llvm/lib/IR/Instructions.cpp  | 16 +
 llvm/lib/IR/Operator.cpp  |  3 +-
 .../Scalar/SeparateConstOffsetFromGEP.cpp |  8 +++
 .../Transforms/Utils/FunctionComparator.cpp   |  6 ++
 llvm/lib/Transforms/Vectorize/VPlan.h |  5 ++
 llvm/test/Assembler/flags.ll  | 43 +
 llvm/test/Transforms/InstCombine/freeze.ll| 22 +++
 llvm/test/Transforms/SimplifyCFG/HoistCode.ll | 60 +++
 llvm/test/tools/llvm-reduce/reduce-flags.ll   | 18 --
 .../deltas/ReduceInstructionFlags.cpp |  4 ++
 22 files changed, 333 insertions(+), 38 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index e2f4d8bfcaeed..aedd1c2281eff 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -11180,6 +11180,8 @@ Syntax:
 
= getelementptr , ptr {,  }*
= getelementptr inbounds , ptr {,  }*
+   = getelementptr nusw , ptr {,  }*
+   = getelementptr nuw , ptr {,  }*
= getelementptr inrange(S,E) , ptr {,  }*
= getelementptr ,  ,  

 
@@ -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
-:ref:`poison value ` if one of the following rules is violated:
-
-*  The base pointer has an *in bounds* address of an allocated object, which
+The ``getelementptr`` instruction may have a number of attributes that impose
+additional rules. If any of the rules are violated, the result value is a
+:ref:`poison value `. In cases where the base is a vector of
+pointers, the attributes apply to each computation element-wise.
+
+For ``nusw`` (no unsigned signed wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the signed value
+   (``trunc nsw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in a signed sense (``mul nsw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in a signed sense (``add nsw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, interpreted as
+   a signed number, does not wrap the index type.
+
+For ``nuw`` (no unsigned wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the unsigned value
+   (``trunc nuw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in an unsigned sense (``mul nuw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in an unsigned sense (``add nuw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, also interpreted as
+   an unsigned number, does not wrap the index type (``add nuw``).
+
+For ``inbounds`` all rules of the ``nusw`` attribute apply. Additionally,
+if the ``getelementptr`` has any non-zero indices, the following rules apply:
+
+ * The base pointer has an *in bounds* address of an allocated object, which
means that it points into an allocated object, or to its end. Note that the
object does not have to be live anymore; being in-bounds of a deallocated
object is sufficient.
-*  If the type of an index is larger than the pointer index type, the
-   truncation to the pointer index type preserves the signed value.
-*  The multiplication of an index by the type size does not wrap the pointer
-   index type in a signed sense (``nsw``).
-*  The successive addition of each offset (without adding the base address) 
does
-   not wrap the pointer index type in a signed sense 

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

[Nikita Popov via cfe-commits]

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.rst | 57 --
 llvm/docs/ReleaseNotes.rst|  1 +
 llvm/include/llvm/AsmParser/LLToken.h |  1 +
 llvm/include/llvm/Bitcode/LLVMBitCodes.h  |  8 +++
 llvm/include/llvm/IR/Instructions.h   | 14 +
 llvm/include/llvm/IR/Operator.h   | 26 +++-
 llvm/lib/AsmParser/LLLexer.cpp|  1 +
 llvm/lib/AsmParser/LLParser.cpp   | 21 ++-
 llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 20 +--
 llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | 11 +++-
 llvm/lib/IR/AsmWriter.cpp |  4 ++
 llvm/lib/IR/Instruction.cpp   | 22 +--
 llvm/lib/IR/Instructions.cpp  | 16 +
 llvm/lib/IR/Operator.cpp  |  3 +-
 .../Scalar/SeparateConstOffsetFromGEP.cpp |  8 +++
 .../Transforms/Utils/FunctionComparator.cpp   |  6 ++
 llvm/lib/Transforms/Vectorize/VPlan.h |  5 ++
 llvm/test/Assembler/flags.ll  | 43 +
 llvm/test/Transforms/InstCombine/freeze.ll| 22 +++
 llvm/test/Transforms/SimplifyCFG/HoistCode.ll | 60 +++
 llvm/test/tools/llvm-reduce/reduce-flags.ll   | 18 --
 .../deltas/ReduceInstructionFlags.cpp |  4 ++
 22 files changed, 333 insertions(+), 38 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index e2f4d8bfcaeed..aedd1c2281eff 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -11180,6 +11180,8 @@ Syntax:
 
= getelementptr , ptr {,  }*
= getelementptr inbounds , ptr {,  }*
+   = getelementptr nusw , ptr {,  }*
+   = getelementptr nuw , ptr {,  }*
= getelementptr inrange(S,E) , ptr {,  }*
= getelementptr ,  ,  

 
@@ -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
-:ref:`poison value ` if one of the following rules is violated:
-
-*  The base pointer has an *in bounds* address of an allocated object, which
+The ``getelementptr`` instruction may have a number of attributes that impose
+additional rules. If any of the rules are violated, the result value is a
+:ref:`poison value `. In cases where the base is a vector of
+pointers, the attributes apply to each computation element-wise.
+
+For ``nusw`` (no unsigned signed wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the signed value
+   (``trunc nsw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in a signed sense (``mul nsw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in a signed sense (``add nsw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, interpreted as
+   a signed number, does not wrap the index type.
+
+For ``nuw`` (no unsigned wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the unsigned value
+   (``trunc nuw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in an unsigned sense (``mul nuw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in an unsigned sense (``add nuw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, also interpreted as
+   an unsigned number, does not wrap the index type (``add nuw``).
+
+For ``inbounds`` all rules of the ``nusw`` attribute apply. Additionally,
+if the ``getelementptr`` has any non-zero indices, the following rules apply:
+
+ * The base pointer has an *in bounds* address of an allocated object, which
means that it points into an allocated object, or to its end. Note that the
object does not have to be live anymore; being in-bounds of a deallocated
object is sufficient.
-*  If the type of an index is larger than the pointer index type, the
-   truncation to the pointer index type preserves the signed value.
-*  The multiplication of an index by the type size does not wrap the pointer
-   index type in a signed sense (``nsw``).
-*  The successive addition of each offset (without adding the base address) 
does
-   not wrap the pointer index type in a signed sense 

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

[Nikita Popov via cfe-commits]

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'm 
stabbing in the dark here.)

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] [flang] [llvm] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

[Nikita Popov via cfe-commits]

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/listinfo/cfe-commits

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

[Nikita Popov via cfe-commits]

@@ -1699,8 +1701,12 @@ Expected 
BitcodeReader::materializeValue(unsigned StartValID,
 I = GetElementPtrInst::Create(BC->SrcElemTy, Ops[0],
   ArrayRef(Ops).drop_front(), "constexpr",
   InsertBB);
-if (BC->Flags)
+if (BC->Flags & (1 << bitc::GEP_INBOUNDS))
   cast(I)->setIsInBounds();
+if (BC->Flags & (1 << bitc::GEP_NUSW))

nikic wrote:

I think using `else if` would be correct here as `setIsInBounds` will also set 
nusw by itself, but keeping all cases separate seems cleaner?

Otherwise we'll have the following code here...
```
if (BC->Flags & (1 << bitc::GEP_INBOUNDS))
  cast(I)->setIsInBounds();
else if (BC->Flags & (1 << bitc::GEP_NUSW))
  cast(I)->setHasNoUnsignedSignedWrap();
if (BC->Flags & (1 << bitc::GEP_NUW))
  cast(I)->setHasNoUnsignedWrap();
```
...at which point it will probably need a comment to explain why there is only 
one `else if` there.

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

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

[Nikita Popov via cfe-commits]

@@ -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 = getelementptr nuw i8, ptr %p, i64 %idx
+  ret ptr %gep
+}
+
+define ptr @gep_inbounds_nuw(ptr %p, i64 %idx) {
+; CHECK: %gep = getelementptr inbounds nuw i8, ptr %p, i64 %idx
+  %gep = getelementptr inbounds nuw i8, ptr %p, i64 %idx
+  ret ptr %gep
+}
+
+define ptr @gep_nusw(ptr %p, i64 %idx) {
+; CHECK: %gep = getelementptr nusw i8, ptr %p, i64 %idx
+  %gep = getelementptr nusw i8, ptr %p, i64 %idx
+  ret ptr %gep
+}
+
+; inbounds implies nusw, so the flag is not printed back.
+define ptr @gep_inbounds_nusw(ptr %p, i64 %idx) {
+; CHECK: %gep = getelementptr inbounds i8, ptr %p, i64 %idx
+  %gep = getelementptr inbounds nusw i8, ptr %p, i64 %idx
+  ret ptr %gep
+}
+
+define ptr @gep_nusw_nuw(ptr %p, i64 %idx) {
+; CHECK: %gep = getelementptr nusw nuw i8, ptr %p, i64 %idx
+  %gep = getelementptr nusw nuw i8, ptr %p, i64 %idx
+  ret ptr %gep
+}
+
+define ptr @gep_inbounds_nusw_nuw(ptr %p, i64 %idx) {
+; CHECK: %gep = getelementptr inbounds nuw i8, ptr %p, i64 %idx
+  %gep = getelementptr inbounds nusw nuw i8, ptr %p, i64 %idx
+  ret ptr %gep
+}
+
+define ptr @gep_nuw_nusw_inbounds(ptr %p, i64 %idx) {
+; CHECK: %gep = getelementptr inbounds nuw i8, ptr %p, i64 %idx
+  %gep = getelementptr nuw nusw inbounds i8, ptr %p, i64 %idx
+  ret ptr %gep
+}
+
+define ptr @const_gep_nuw(ptr %p, i64 %idx) {
+; CHECK: ret ptr getelementptr nuw (i8, ptr @addr, i64 100)
+  ret ptr getelementptr nuw (i8, ptr @addr, i64 100)
+}
+
+define ptr @const_gep_inbounds_nuw(ptr %p, i64 %idx) {
+; CHECK: ret ptr getelementptr inbounds nuw (i8, ptr @addr, i64 100)
+  ret ptr getelementptr inbounds nuw (i8, ptr @addr, i64 100)
+}
+
+define ptr @const_gep_nusw(ptr %p, i64 %idx) {
+; CHECK: ret ptr getelementptr nusw (i8, ptr @addr, i64 100)
+  ret ptr getelementptr nusw (i8, ptr @addr, i64 100)
+}
+
+; inbounds implies nusw, so the flag is not printed back.
+define ptr @const_gep_inbounds_nusw(ptr %p, i64 %idx) {
+; CHECK: ret ptr getelementptr inbounds (i8, ptr @addr, i64 100)
+  ret ptr getelementptr inbounds nusw (i8, ptr @addr, i64 100)
+}
+
+define ptr @const_gep_nusw_nuw(ptr %p, i64 %idx) {
+; CHECK: ret ptr getelementptr nusw nuw (i8, ptr @addr, i64 100)
+  ret ptr getelementptr nusw nuw (i8, ptr @addr, i64 100)
+}
+
+define ptr @const_gep_inbounds_nusw_nuw(ptr %p, i64 %idx) {
+; CHECK: ret ptr getelementptr inbounds nuw (i8, ptr @addr, i64 100)
+  ret ptr getelementptr inbounds nusw nuw (i8, ptr @addr, i64 100)
+}
+
+define ptr @const_gep_nuw_nusw_inbounds(ptr %p, i64 %idx) {
+; CHECK: ret ptr getelementptr inbounds nuw (i8, ptr @addr, i64 100)
+  ret ptr getelementptr nuw nusw inbounds (i8, ptr @addr, i64 100)
+}

nikic wrote:

Done

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

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

[Nikita Popov via cfe-commits]

@@ -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
-:ref:`poison value ` if one of the following rules is violated:
-
-*  The base pointer has an *in bounds* address of an allocated object, which
+The ``getelementptr`` instruction may have a number of attributes that impose
+additional rules. If any of the rules are violated, the result value is a
+:ref:`poison value `. In cases where the base is a vector of
+pointers, the attributes apply to each computation element-wise.
+
+For ``nusw`` (no unsigned signed wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the signed value
+   (``trunc nsw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in a signed sense (``mul nsw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in a signed sense (``add nsw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, interpreted as
+   a signed number, does not wrap the index type.

nikic wrote:

> missing '(`add nsw`)' at the end of this?

No, because the base is unsigned here. This would be `add nusw` if it existed.

> Also maybe im a bit confused, but should this not be 'pointer index type'?

Yeah, I've updated this and other places to use "pointer index type".

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

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

[Nikita Popov via cfe-commits]

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.rst | 57 --
 llvm/docs/ReleaseNotes.rst|  1 +
 llvm/include/llvm/AsmParser/LLToken.h |  1 +
 llvm/include/llvm/Bitcode/LLVMBitCodes.h  |  8 +++
 llvm/include/llvm/IR/Instructions.h   | 14 +
 llvm/include/llvm/IR/Operator.h   | 26 +++-
 llvm/lib/AsmParser/LLLexer.cpp|  1 +
 llvm/lib/AsmParser/LLParser.cpp   | 21 ++-
 llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 20 +--
 llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | 11 +++-
 llvm/lib/IR/AsmWriter.cpp |  4 ++
 llvm/lib/IR/Instruction.cpp   | 22 +--
 llvm/lib/IR/Instructions.cpp  | 16 +
 llvm/lib/IR/Operator.cpp  |  3 +-
 .../Scalar/SeparateConstOffsetFromGEP.cpp | 13 
 .../Transforms/Utils/FunctionComparator.cpp   |  6 ++
 llvm/lib/Transforms/Vectorize/VPlan.h |  5 ++
 llvm/test/Assembler/flags.ll  | 43 +
 llvm/test/Transforms/InstCombine/freeze.ll| 22 +++
 llvm/test/Transforms/SimplifyCFG/HoistCode.ll | 60 +++
 llvm/test/tools/llvm-reduce/reduce-flags.ll   | 18 --
 .../deltas/ReduceInstructionFlags.cpp |  4 ++
 22 files changed, 338 insertions(+), 38 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 6291a4e57919a5..7aeed82ab84df7 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -11180,6 +11180,8 @@ Syntax:
 
= getelementptr , ptr {,  }*
= getelementptr inbounds , ptr {,  }*
+   = getelementptr nusw , ptr {,  }*
+   = getelementptr nuw , ptr {,  }*
= getelementptr inrange(S,E) , ptr {,  }*
= getelementptr ,  ,  

 
@@ -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
-:ref:`poison value ` if one of the following rules is violated:
-
-*  The base pointer has an *in bounds* address of an allocated object, which
+The ``getelementptr`` instruction may have a number of attributes that impose
+additional rules. If any of the rules are violated, the result value is a
+:ref:`poison value `. In cases where the base is a vector of
+pointers, the attributes apply to each computation element-wise.
+
+For ``nusw`` (no unsigned signed wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the signed value
+   (``trunc nsw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in a signed sense (``mul nsw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in a signed sense (``add nsw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, interpreted as
+   a signed number, does not wrap the index type.
+
+For ``nuw`` (no unsigned wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the unsigned value
+   (``trunc nuw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in an unsigned sense (``mul nuw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in an unsigned sense (``add nuw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, also interpreted as
+   an unsigned number, does not wrap the index type (``add nuw``).
+
+For ``inbounds`` all rules of the ``nusw`` attribute apply. Additionally,
+if the ``getelementptr`` has any non-zero indices, the following rules apply:
+
+ * The base pointer has an *in bounds* address of an allocated object, which
means that it points into an allocated object, or to its end. Note that the
object does not have to be live anymore; being in-bounds of a deallocated
object is sufficient.
-*  If the type of an index is larger than the pointer index type, the
-   truncation to the pointer index type preserves the signed value.
-*  The multiplication of an index by the type size does not wrap the pointer
-   index type in a signed sense (``nsw``).
-*  The successive addition of each offset (without adding the base address) 
does
-   not wrap the pointer index type in a signed sense 

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

[Nikita Popov via cfe-commits]

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 that need to be modified to full propagate the flags 
everywhere.

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

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

[Nikita Popov via cfe-commits]

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.rst | 57 --
 llvm/docs/ReleaseNotes.rst|  1 +
 llvm/include/llvm/AsmParser/LLToken.h |  1 +
 llvm/include/llvm/Bitcode/LLVMBitCodes.h  |  8 +++
 llvm/include/llvm/IR/Instructions.h   | 14 +
 llvm/include/llvm/IR/Operator.h   | 26 +++-
 llvm/lib/AsmParser/LLLexer.cpp|  1 +
 llvm/lib/AsmParser/LLParser.cpp   | 21 ++-
 llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 20 +--
 llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | 11 +++-
 llvm/lib/IR/AsmWriter.cpp |  4 ++
 llvm/lib/IR/Instruction.cpp   | 22 +--
 llvm/lib/IR/Instructions.cpp  | 16 +
 llvm/lib/IR/Operator.cpp  |  3 +-
 .../Scalar/SeparateConstOffsetFromGEP.cpp | 13 
 .../Transforms/Utils/FunctionComparator.cpp   |  6 ++
 llvm/lib/Transforms/Vectorize/VPlan.h |  5 ++
 llvm/test/Assembler/flags.ll  | 43 +
 llvm/test/Transforms/InstCombine/freeze.ll| 22 +++
 llvm/test/Transforms/SimplifyCFG/HoistCode.ll | 60 +++
 llvm/test/tools/llvm-reduce/reduce-flags.ll   | 18 --
 .../deltas/ReduceInstructionFlags.cpp |  4 ++
 22 files changed, 338 insertions(+), 38 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 6291a4e57919a5..7aeed82ab84df7 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -11180,6 +11180,8 @@ Syntax:
 
= getelementptr , ptr {,  }*
= getelementptr inbounds , ptr {,  }*
+   = getelementptr nusw , ptr {,  }*
+   = getelementptr nuw , ptr {,  }*
= getelementptr inrange(S,E) , ptr {,  }*
= getelementptr ,  ,  

 
@@ -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
-:ref:`poison value ` if one of the following rules is violated:
-
-*  The base pointer has an *in bounds* address of an allocated object, which
+The ``getelementptr`` instruction may have a number of attributes that impose
+additional rules. If any of the rules are violated, the result value is a
+:ref:`poison value `. In cases where the base is a vector of
+pointers, the attributes apply to each computation element-wise.
+
+For ``nusw`` (no unsigned signed wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the signed value
+   (``trunc nsw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in a signed sense (``mul nsw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in a signed sense (``add nsw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, interpreted as
+   a signed number, does not wrap the index type.
+
+For ``nuw`` (no unsigned wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the unsigned value
+   (``trunc nuw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in an unsigned sense (``mul nuw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in an unsigned sense (``add nuw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, also interpreted as
+   an unsigned number, does not wrap the index type (``add nuw``).
+
+For ``inbounds`` all rules of the ``nusw`` attribute apply. Additionally,
+if the ``getelementptr`` has any non-zero indices, the following rules apply:
+
+ * The base pointer has an *in bounds* address of an allocated object, which
means that it points into an allocated object, or to its end. Note that the
object does not have to be live anymore; being in-bounds of a deallocated
object is sufficient.
-*  If the type of an index is larger than the pointer index type, the
-   truncation to the pointer index type preserves the signed value.
-*  The multiplication of an index by the type size does not wrap the pointer
-   index type in a signed sense (``nsw``).
-*  The successive addition of each offset (without adding the base address) 
does
-   not wrap the pointer index type in a signed sense 

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

[Nikita Popov via 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_nowrap)`, where I've had 
to touch code but opted to not infer or precisely preserve the new flags, so as 
to keep this as NFC as possible and make sure any changes of that kind get test 
coverage when they are made.

>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.rst | 57 --
 llvm/docs/ReleaseNotes.rst|  1 +
 llvm/include/llvm/AsmParser/LLToken.h |  1 +
 llvm/include/llvm/Bitcode/LLVMBitCodes.h  |  8 +++
 llvm/include/llvm/IR/Instructions.h   | 14 +
 llvm/include/llvm/IR/Operator.h   | 26 +++-
 llvm/lib/AsmParser/LLLexer.cpp|  1 +
 llvm/lib/AsmParser/LLParser.cpp   | 21 ++-
 llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 20 +--
 llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | 11 +++-
 llvm/lib/IR/AsmWriter.cpp |  4 ++
 llvm/lib/IR/Instruction.cpp   | 22 +--
 llvm/lib/IR/Instructions.cpp  | 16 +
 llvm/lib/IR/Operator.cpp  |  3 +-
 .../Scalar/SeparateConstOffsetFromGEP.cpp | 13 
 .../Transforms/Utils/FunctionComparator.cpp   |  6 ++
 llvm/lib/Transforms/Vectorize/VPlan.h |  5 ++
 llvm/test/Assembler/flags.ll  | 43 +
 llvm/test/Transforms/InstCombine/freeze.ll| 22 +++
 llvm/test/Transforms/SimplifyCFG/HoistCode.ll | 60 +++
 llvm/test/tools/llvm-reduce/reduce-flags.ll   | 18 --
 .../deltas/ReduceInstructionFlags.cpp |  4 ++
 22 files changed, 338 insertions(+), 38 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 6291a4e57919a5..7aeed82ab84df7 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -11180,6 +11180,8 @@ Syntax:
 
= getelementptr , ptr {,  }*
= getelementptr inbounds , ptr {,  }*
+   = getelementptr nusw , ptr {,  }*
+   = getelementptr nuw , ptr {,  }*
= getelementptr inrange(S,E) , ptr {,  }*
= getelementptr ,  ,  

 
@@ -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
-:ref:`poison value ` if one of the following rules is violated:
-
-*  The base pointer has an *in bounds* address of an allocated object, which
+The ``getelementptr`` instruction may have a number of attributes that impose
+additional rules. If any of the rules are violated, the result value is a
+:ref:`poison value `. In cases where the base is a vector of
+pointers, the attributes apply to each computation element-wise.
+
+For ``nusw`` (no unsigned signed wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the signed value
+   (``trunc nsw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in a signed sense (``mul nsw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in a signed sense (``add nsw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, interpreted as
+   a signed number, does not wrap the index type.
+
+For ``nuw`` (no unsigned wrap):
+
+ * If the type of an index is larger than the pointer index type, the
+   truncation to the pointer index type preserves the unsigned value
+   (``trunc nuw``).
+ * The multiplication of an index by the type size does not wrap the pointer
+   index type in an unsigned sense (``mul nuw``).
+ * The successive addition of each offset (without adding the base address)
+   does not wrap the pointer index type in an unsigned sense (``add nuw``).
+ * The successive addition of the current address, truncated to the index type
+   and interpreted as an unsigned number, and each offset, also interpreted as
+   an unsigned number, does not wrap the index type (``add nuw``).
+
+For ``inbounds`` all rules of the ``nusw`` attribute apply. Additionally,
+if the ``getelementptr`` has any non-zero indices, the following rules apply:
+
+ * The base pointer has an *in bounds* address of an allocated object, which
means that it points into an allocated object, or to its end. Note that the
object does not have to be live anymore; being in-bounds of a 

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

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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 
`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] [compiler-rt] [llvm] [ConstantFolding] Canonicalize constexpr GEPs to i8 (PR #89872)

[Nikita Popov via cfe-commits]

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
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nikita Popov via 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 bounds.
-  // This makes it easy to determine if the getelementptr is "inbounds".
-
-  // For GEPs of GlobalValues, use the value type, otherwise use an i8 GEP.
-  if (auto *GV = dyn_cast(Ptr))
-SrcElemTy = GV->getValueType();
-  else
-SrcElemTy = Type::getInt8Ty(Ptr->getContext());
-
-  if (!SrcElemTy->isSized())
-return nullptr;
-
-  Type *ElemTy = SrcElemTy;
-  SmallVector Indices = DL.getGEPIndicesForOffset(ElemTy, Offset);
-  if (Offset != 0)
-return nullptr;
-
-  // Try to add additional zero indices to reach the desired result element
-  // type.
-  // TODO: Should we avoid extra zero indices if ResElemTy can't be reached and
-  // we'll have to insert a bitcast anyway?
-  while (ElemTy != ResElemTy) {
-Type *NextTy = GetElementPtrInst::getTypeAtIndex(ElemTy, (uint64_t)0);
-if (!NextTy)
-  break;
-
-Indices.push_back(APInt::getZero(isa(ElemTy) ? 32 : BitWidth));
-ElemTy = NextTy;
+  // Try to infer inbounds for GEPs of globals.
+  if (!InBounds && Offset.isNonNegative()) {

nikic wrote:

https://github.com/llvm/llvm-project/blob/main/llvm/test/Transforms/GlobalOpt/large-element-size.ll
 gets an incorrect inbounds without the check.

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

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

[Nikita Popov via 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

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

[Nikita Popov via 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

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

[Nikita Popov via 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% reduction in text size 
(https://llvm-compile-time-tracker.com/compare.php?from=ef2ca97f48f1aee1483f0c29de5ba52979bec454=18376810f359dbd39d2a0aa0ddfc0f7f50eac199=size-text)
 so maybe the tradeoff is reasonable even for `O0`.

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

[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

[Nikita Popov via cfe-commits]

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=a8fd0d029dca7d17eee72d0445223c2fe1ee7758=instructions%3Au=interestingness).
 Nothing terrible (it doesn't seem to be an across-the-board regression), just 
wanted to let you know in case this is unexpected.

https://github.com/llvm/llvm-project/pull/84050
___
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)

[Nikita Popov via cfe-commits]

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 progess.

The major patches have been https://github.com/llvm/llvm-project/pull/68882, 
https://github.com/llvm/llvm-project/pull/84341 and this one. There have been 
some smaller changes in between to fix related optimization regressions.


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

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

[Nikita Popov via 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 bounds.
-  // This makes it easy to determine if the getelementptr is "inbounds".
-
-  // For GEPs of GlobalValues, use the value type, otherwise use an i8 GEP.
-  if (auto *GV = dyn_cast(Ptr))
-SrcElemTy = GV->getValueType();
-  else
-SrcElemTy = Type::getInt8Ty(Ptr->getContext());
-
-  if (!SrcElemTy->isSized())
-return nullptr;
-
-  Type *ElemTy = SrcElemTy;
-  SmallVector Indices = DL.getGEPIndicesForOffset(ElemTy, Offset);
-  if (Offset != 0)
-return nullptr;
-
-  // Try to add additional zero indices to reach the desired result element
-  // type.
-  // TODO: Should we avoid extra zero indices if ResElemTy can't be reached and
-  // we'll have to insert a bitcast anyway?
-  while (ElemTy != ResElemTy) {
-Type *NextTy = GetElementPtrInst::getTypeAtIndex(ElemTy, (uint64_t)0);
-if (!NextTy)
-  break;
-
-Indices.push_back(APInt::getZero(isa(ElemTy) ? 32 : BitWidth));
-ElemTy = NextTy;
+  // Try to infer inbounds for GEPs of globals.
+  if (!InBounds && Offset.isNonNegative()) {
+bool CanBeNull, CanBeFreed;
+uint64_t DerefBytes =
+Ptr->getPointerDereferenceableBytes(DL, CanBeNull, CanBeFreed);
+InBounds = DerefBytes != 0 && !CanBeNull && Offset.sle(DerefBytes);

nikic wrote:

I don't think we'd want to remove it at this point as it's still used in some 
key places like initial IR construction in clang -- longer term, I'd like to 
get rid of the two separate constant folding implementations altogether.

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

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

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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 bounds.
-  // This makes it easy to determine if the getelementptr is "inbounds".
-
-  // For GEPs of GlobalValues, use the value type, otherwise use an i8 GEP.
-  if (auto *GV = dyn_cast(Ptr))
-SrcElemTy = GV->getValueType();
-  else
-SrcElemTy = Type::getInt8Ty(Ptr->getContext());
-
-  if (!SrcElemTy->isSized())
-return nullptr;
-
-  Type *ElemTy = SrcElemTy;
-  SmallVector Indices = DL.getGEPIndicesForOffset(ElemTy, Offset);
-  if (Offset != 0)
-return nullptr;
-
-  // Try to add additional zero indices to reach the desired result element
-  // type.
-  // TODO: Should we avoid extra zero indices if ResElemTy can't be reached and
-  // we'll have to insert a bitcast anyway?
-  while (ElemTy != ResElemTy) {
-Type *NextTy = GetElementPtrInst::getTypeAtIndex(ElemTy, (uint64_t)0);
-if (!NextTy)
-  break;
-
-Indices.push_back(APInt::getZero(isa(ElemTy) ? 32 : BitWidth));
-ElemTy = NextTy;
+  // Try to infer inbounds for GEPs of globals.
+  if (!InBounds && Offset.isNonNegative()) {
+bool CanBeNull, CanBeFreed;
+uint64_t DerefBytes =
+Ptr->getPointerDereferenceableBytes(DL, CanBeNull, CanBeFreed);
+InBounds = DerefBytes != 0 && !CanBeNull && Offset.sle(DerefBytes);

nikic wrote:

I've added this inference in this patch, because we lose out on this inference 
in the DataLayout-independent constant folding: 
https://github.com/llvm/llvm-project/blob/88b6186af3908c55b357858eb348b5143f21c289/llvm/lib/IR/ConstantFold.cpp#L1717-L1724
 As such, we need a (more powerful version of) this inference in the 
DataLayout-aware constant folding code.

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

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

[Nikita Popov via 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/Transforms/InstCombine/InstCombineInternal.h 
> :
> 
> > @@ -433,7 +433,7 @@ class LLVM_LIBRARY_VISIBILITY InstCombinerImpl final
>Value *foldAndOrOfICmpsOfAndWithPow2(ICmpInst *LHS, ICmpInst *RHS,
> Instruction *CxtI, bool IsAnd,
> bool IsLogical = false);
> -  Value *matchSelectFromAndOr(Value *A, Value *B, Value *C, Value *D,
> 
> You could fix the warning by using vastly different names for the function 
> parameters?
> 
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because your review was requested.Message ID: 
> ***@***.***>
> 

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] [mlir] Fix Definition Mismatches (PR #89294)

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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 of experimental. It 
> seems to be a permanent prefix

At least the vector.reduce intrinsics were moved out of the experimental 
namespace.

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

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

[Nikita Popov via 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=4082a7554521572a65a5a0008c4661a534df659d=instructions%3Au).

Probably most damning are the times for the clang build itself 
(https://llvm-compile-time-tracker.com/compare_clang.php?from=184ba038ac1d444980b3e554b0057f3f30c516ab=4082a7554521572a65a5a0008c4661a534df659d=instructions%3Au=interestingness)
 where files like X86ISelDAGToDAG.cpp regress by >3% even in an optimized build.

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

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

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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

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

[Nikita Popov via 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);
+Changed = true;
+  }
+  if (!Trunc.hasNoUnsignedWrap() &&
+  MaskedValueIsZero(Src, APInt::getBitsSetFrom(SrcWidth, DestWidth),
+/*Depth=*/0, )) {
+Trunc.setHasNoUnsignedWrap(true);
+Changed = true;

nikic wrote:

Okay, I won't insist on this.

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)

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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

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

[Nikita Popov via 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 integrating 
> too deeply?

I don't think this is important for uitofp nneg, mainly because we only have 
very few folds for it, so there's just not a great deal of potential for things 
to go wrong...

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] Add canonicalization of `sitofp` -> `uitofp nneg` (PR #88299)

[Nikita Popov via cfe-commits]

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.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nikita Popov via cfe-commits]

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)

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

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

[Nikita Popov via 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);
+Changed = true;
+  }
+  if (!Trunc.hasNoUnsignedWrap() &&
+  MaskedValueIsZero(Src, APInt::getBitsSetFrom(SrcWidth, DestWidth),
+/*Depth=*/0, )) {
+Trunc.setHasNoUnsignedWrap(true);
+Changed = true;

nikic wrote:

We can't infer nsw, but we can infer nuw. Do you see any reason why doing this 
in SimplifyDemanded would be problematic?

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)

[Nikita Popov via 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);
+Changed = true;
+  }
+  if (!Trunc.hasNoUnsignedWrap() &&
+  MaskedValueIsZero(Src, APInt::getBitsSetFrom(SrcWidth, DestWidth),
+/*Depth=*/0, )) {
+Trunc.setHasNoUnsignedWrap(true);
+Changed = true;

nikic wrote:

Can we infer this in SimplifyDemanded instead, where we already have the 
KnownBits of the trunc arg?

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] 3eb8063 - [CodeGen] Fix test on 32-bit targets (NFC)

[Nikita Popov via cfe-commits]

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

LOG: [CodeGen] Fix test on 32-bit targets (NFC)

The range here will be different for 32-bit targets. Use a wildcard,
just like all te other target-sensitive parts in this test.

Added: 


Modified: 
clang/test/CodeGenCXX/copy-constructor-synthesis-2.cpp

Removed: 




diff  --git a/clang/test/CodeGenCXX/copy-constructor-synthesis-2.cpp 
b/clang/test/CodeGenCXX/copy-constructor-synthesis-2.cpp
index 4f96a3ae670774..ae0c3a26c597ea 100644
--- a/clang/test/CodeGenCXX/copy-constructor-synthesis-2.cpp
+++ b/clang/test/CodeGenCXX/copy-constructor-synthesis-2.cpp
@@ -24,4 +24,4 @@ struct A { virtual void a(); };
 A x(A& y) { return y; }
 
 // CHECK: define linkonce_odr {{.*}} @_ZN1AC1ERKS_(ptr {{.*}}%this, ptr 
noundef nonnull align {{[0-9]+}} dereferenceable({{[0-9]+}}) %0) unnamed_addr
-// CHECK: store ptr getelementptr inbounds inrange(-16, 8) ({ [3 x ptr] }, ptr 
@_ZTV1A, i32 0, i32 0, i32 2)
+// CHECK: store ptr getelementptr inbounds inrange(-{{[0-9]+}}, {{[0-9]+}}) ({ 
[3 x ptr] }, ptr @_ZTV1A, i32 0, i32 0, i32 2)



___
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)

[Nikita Popov via cfe-commits]

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

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

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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 derived from an inrange getelementptr constant, which is
-  // sufficient to allow us to apply the splitting transform.
+  const DataLayout  = GV.getParent()->getDataLayout();
+  const StructLayout *SL = DL.getStructLayout(Init->getType());
+  ArrayRef MemberOffsets = SL->getMemberOffsets();
+  unsigned IndexWidth = DL.getIndexTypeSizeInBits(GV.getType());
+
+  // Verify that each user of the global is an inrange getelementptr constant,
+  // and collect information on how it relates to the global.
+  struct GEPInfo {
+GEPOperator *GEP;
+unsigned MemberIndex;
+APInt MemberRelativeOffset;
+
+GEPInfo(GEPOperator *GEP, unsigned MemberIndex, APInt MemberRelativeOffset)
+: GEP(GEP), MemberIndex(MemberIndex),
+  MemberRelativeOffset(std::move(MemberRelativeOffset)) {}
+  };
+  SmallVector Infos;
   for (User *U : GV.users()) {
-if (!isa(U))
+auto *GEP = dyn_cast(U);
+if (!GEP)
   return false;
 
-auto *GEP = dyn_cast(U);
-if (!GEP || !GEP->getInRangeIndex() || *GEP->getInRangeIndex() != 1 ||
-!isa(GEP->getOperand(1)) ||
-!cast(GEP->getOperand(1))->isZero() ||
-!isa(GEP->getOperand(2)))
+std::optional InRange = GEP->getInRange();
+if (!InRange)
+  return false;
+
+APInt Offset(IndexWidth, 0);
+if (!GEP->accumulateConstantOffset(DL, Offset))
+  return false;
+
+// Determine source-relative inrange.
+ConstantRange SrcInRange = InRange->sextOrTrunc(IndexWidth).add(Offset);
+
+// Check that the GEP offset is in the range (treating upper bound as
+// inclusive here).
+if (!SrcInRange.contains(Offset) && SrcInRange.getUpper() != Offset)
+  return false;
+
+// Find which struct member the range corresponds to.
+if (SrcInRange.getLower().uge(SL->getSizeInBytes()))
   return false;
+
+unsigned MemberIndex =
+SL->getElementContainingOffset(SrcInRange.getLower().getZExtValue());

nikic wrote:

I think this is already implied by the check directly before this (note that it 
uses uge rather than sge, so will also reject negative numbers -- unless the 
struct size becomes negative, of course...).

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)

[Nikita Popov via cfe-commits]

@@ -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-indexed getelementptr folding.
+; Verify that inrange doesn't inhibit over-indexed getelementptr folding,
+; but does inhibit combining two GEPs where the inner one has inrange (this
+; will be done when DataLayout is available instead).
 
 @nestedarray = global [2 x [4 x ptr]] zeroinitializer
 
-; CHECK: @nestedarray.1 = alias ptr, getelementptr inbounds ([2 x [4 x ptr]], 
ptr @nestedarray, inrange i32 0, i64 1, i32 0)
-@nestedarray.1 = alias ptr, getelementptr inbounds ([2 x [4 x ptr]], ptr 
@nestedarray, inrange i32 0, i32 0, i32 4)
+; CHECK: @nestedarray.1 = alias ptr, getelementptr inbounds inrange(-32, 32) 
([2 x [4 x ptr]], ptr @nestedarray, i32 0, i64 1, i32 0)
+@nestedarray.1 = alias ptr, getelementptr inbounds inrange(-32, 32) ([2 x [4 x 
ptr]], ptr @nestedarray, i32 0, i32 0, i32 4)
 
-; CHECK: @nestedarray.2 = alias ptr, getelementptr inbounds ([2 x [4 x ptr]], 
ptr @nestedarray, i32 0, inrange i32 0, i32 4)
-@nestedarray.2 = alias ptr, getelementptr inbounds ([2 x [4 x ptr]], ptr 
@nestedarray, i32 0, inrange i32 0, i32 4)
+; CHECK: @nestedarray.2 = alias ptr, getelementptr inbounds inrange(0, 1) ([2 
x [4 x ptr]], ptr @nestedarray, i32 0, i64 1, i32 0)
+@nestedarray.2 = alias ptr, getelementptr inbounds inrange(0, 1) ([2 x [4 x 
ptr]], ptr @nestedarray, i32 0, i32 0, i32 4)
 
-; CHECK: @nestedarray.3 = alias ptr, getelementptr inbounds ([2 x [4 x ptr]], 
ptr @nestedarray, i32 0, inrange i32 0)
-@nestedarray.3 = alias ptr, getelementptr inbounds ([4 x ptr], ptr 
getelementptr inbounds ([2 x [4 x ptr]], ptr @nestedarray, i32 0, inrange i32 
0), i32 0, i32 0)
+; CHECK: @nestedarray.3 = alias ptr, getelementptr inbounds inrange(0, 4) ([4 
x ptr], ptr @nestedarray, i32 0, i32 0)
+@nestedarray.3 = alias ptr, getelementptr inbounds inrange(0, 4) ([4 x ptr], 
ptr getelementptr inbounds ([2 x [4 x ptr]], ptr @nestedarray, i32 0, i32 0), 
i32 0, i32 0)

nikic wrote:

These kinds of all zero GEPs usually get folded away during constant expression 
construction. However, they *are* retained if doing so would lose an inrange 
attribute.

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] Sanitizer: Support -fwrapv with -fsanitize=signed-integer-overflow (PR #82432)

[Nikita Popov via cfe-commits]

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 expand to 
> signed-integer-overflow: [#80089 
> (comment)](https://github.com/llvm/llvm-project/pull/80089#issuecomment-1945202620)
> 
> Perhaps you have run into some convenience issues? #85501 for the 
> signed-integer-overflow suppresion.

I don't use `-fwrapv` myself, so this is more a philosophical consideration. It 
seems wrong to me for `-fsanitize=undefined` to report something as undefined 
behavior which is not undefined behavior in the used language dialect. 
`-fsanitize=undefined` already has a lot of checks that are conditioned on the 
used language dialect, so excluding the signed overflow case in particular from 
that general approach it is a bit odd.

Thanks for putting up the patch!

https://github.com/llvm/llvm-project/pull/82432
___
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)

[Nikita Popov via cfe-commits]

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-commits

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

[Nikita Popov via cfe-commits]

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 for adding the nneg flag.

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)

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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

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

[Nikita Popov via 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

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

[Nikita Popov via 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

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

[Nikita Popov via 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
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nikita Popov via cfe-commits]

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
___
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)

[Nikita Popov via cfe-commits]

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 to instruction 
GEP / non-constant indices in the future.

If we have something like
```
struct Foo { int a, int b, int c };
struct Foo foo[100];
fn([x]);
```
then we could pass `ptradd ptr inrange(0, 12) @foo, i64 %x * 12` to the 
function and know (for AA purposes) that it only accesses a single struct in 
the array.

This would also be consistent with the alternative intrinsic based 
representation, which would go something like `%p = ptradd ptr @foo, i64 %x * 
12; %p2 = call @llvm.memory.region.decl.p0(ptr %p, i64 0, i64 12)`.

-

With that in mind, I'm leaning towards keeping the result-relative encoding. 
For constant GEPs it makes little difference because we can also ways just 
add/subtract the necessary offset, but this seems more future-proof if we do 
decide to extend to instructions.

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)

[Nikita Popov via cfe-commits]

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 without a dummy ptradd 0.

Hm no, the result-relative case can obviously also represent this, just need to 
move it to the first one:
```
%p1 = ptradd ptr inrange(0, 40) %base, i32 %outer_idx * 44
%p2 = ptradd ptr %p1, i32 %inner_idx * 4
```

In a sense this is more natural because the restriction is logically introduced 
by the first ptradd, not by the second one.


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)

[Nikita Popov via cfe-commits]

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 GEP using an intrinsic instead.

(Technically a constant expression GEP can also have a dynamic index, but that 
case is not practically relevant.)

> Stuff like
> 
> ```
>   %gep = getelementptr [50 x {i32, [10 x i32]}], ptr %base, i32 0, i32 
> %outer_idx, i32 1, i32 %inner_idx
> ```
> 
> The current representation allows an `inrange` on the second-to-last index 
> which to my understanding restricts the range to the `[10 x i32]` into which 
> `%gep` falls structurally.
> 
> It seems like neither proposed representation is able to capture that in a 
> single `ptradd` (it could be captured with a sequence of two `ptradd`s, but 
> that's an awkward tradeoff).
>
> The first proposed representation at least allows handling the case when 
> there is only a single dynamic index, and the `inrange` is to the right of it.

ptradd wouldn't support multi-index GEPs anyway, so the representation would be 
something like
```
%p1 = ptradd ptr %base, i32 %outer_idx * 44
%p2 = ptradd ptr %p1, i32 4
%p3 = ptradd ptr %p2, i32 %inner_idx * 4
```
if we support scaling inside ptradd (or separate multiply/shift instructions 
otherwise). Where `%p1` likely gets LICMed and/or CSEd.

If we did support inrange on non-constant ptradd then we would encode the 
constraints that it's inrange of the inner array as
```
; relative to source
%p2 = ptradd ptr inrange(4, 44) %p1, i32 4
; relative to result
%p2 = ptradd ptr inrange(0, 40) %p1, i32 4
```

Though if we consider a variant where we don't have that extra constant ptradd 
(i.e. drop the struct with the `i32` element):
```
%p1 = ptradd ptr %base, i32 %outer_idx * 44
%p2 = ptradd ptr %p1, i32 %inner_idx * 4
```
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 without a dummy ptradd 0.

> (I guess this is an extension to @aeubanks' point. It feels like `inrange` 
> _should_ be useful for things like alias analysis. But I guess it's not used 
> for that at the moment.)

If we supported inrange on instruction GEP, then yes, it would be useful for AA.



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)

[Nikita Popov via cfe-commits]

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) (i8, ptr @vt, i64 48)
```
would mean that `[-16, 16)` of the *result* is inrange, which would correspond 
to `[32, 64)` of the source.

An alternative would be to make inrange relative to the source pointer instead, 
in which case it would be:
```
getelementptr inbounds inrange(32, 64) (i8, ptr @vt, i64 48)
```

Does anyone have thoughts on which would be better?

I feel like I must have had a reason to pick this when writing the RFC, but I 
don't remember what it was... I'm starting to lean towards using the second 
form, because it will always give the same range regardless of which specific 
vtable pointer you point to.

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)

[Nikita Popov via 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

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

[Nikita Popov via 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 splitting.

Currently, inrange is specified as follows:

```
getelementptr inbounds ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, inrange i32 
1, i64 2)
```

The `inrange` is placed on a GEP index, and all accesses must be "in range" of 
that index. The proposed new representation is as follows:

```
getelementptr inbounds inrange(-16, 16) ({ [4 x ptr], [4 x ptr] }, ptr 
@_ZTV4base, i64 0, i32 1, i64 2)
```

This specifies which offsets are "in range" of the GEP result. The new 
representation will continue working when canonicalizing to ptradd 
representation:

```
getelementptr inbounds inrange(-16, 16) (i8, ptr @_ZTV4base, i64 48)
```

>From 569311c751be87630bb8c7ea4042aa77e6f2fd8e Mon Sep 17 00:00:00 2001
From: Nikita Popov 
Date: Tue, 20 Feb 2024 16:53:07 +0100
Subject: [PATCH] wip

---
 clang/lib/CodeGen/CGVTT.cpp   | 14 +++-
 clang/lib/CodeGen/ItaniumCXXABI.cpp   | 21 +++--
 .../diamond-virtual-inheritance.cpp   |  6 +-
 clang/test/CodeGenCXX/auto-var-init.cpp   |  4 +-
 clang/test/CodeGenCXX/const-init-cxx11.cpp|  6 +-
 ...ata_use_device_ptr_inheritance_codegen.cpp | 12 +--
 llvm/docs/LangRef.rst | 20 ++---
 llvm/include/llvm/AsmParser/LLParser.h|  4 +-
 llvm/include/llvm/Bitcode/LLVMBitCodes.h  |  3 +-
 llvm/include/llvm/IR/ConstantFold.h   |  2 +-
 llvm/include/llvm/IR/Constants.h  | 13 +--
 llvm/include/llvm/IR/Operator.h   |  7 +-
 llvm/lib/Analysis/ConstantFolding.cpp | 42 +-
 llvm/lib/AsmParser/LLParser.cpp   | 57 +
 llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 83 ++-
 llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | 23 -
 llvm/lib/IR/AsmWriter.cpp | 10 +--
 llvm/lib/IR/ConstantFold.cpp  | 35 +++-
 llvm/lib/IR/Constants.cpp | 28 ---
 llvm/lib/IR/ConstantsContext.h| 51 +---
 llvm/lib/IR/Operator.cpp  |  8 +-
 .../AMDGPU/AMDGPULowerBufferFatPointers.cpp   |  2 +-
 llvm/lib/Transforms/IPO/GlobalSplit.cpp   |  5 +-
 .../Transforms/Utils/FunctionComparator.cpp   | 16 +++-
 llvm/test/Assembler/getelementptr.ll  | 24 +++---
 .../GlobalDCE/virtual-functions-base-call.ll  |  4 +-
 .../virtual-functions-base-pointer-call.ll|  4 +-
 .../virtual-functions-derived-call.ll |  4 +-
 .../virtual-functions-derived-pointer-call.ll |  4 +-
 .../GlobalDCE/virtual-functions-novfe.ll  |  4 +-
 .../virtual-functions-visibility-post-lto.ll  |  6 +-
 .../virtual-functions-visibility-pre-lto.ll   |  6 +-
 .../Transforms/GlobalDCE/virtual-functions.ll |  4 +-
 llvm/test/Transforms/GlobalDCE/vtable-rtti.ll |  2 +-
 llvm/test/Transforms/GlobalSplit/basic.ll | 14 ++--
 llvm/test/Transforms/Inline/devirtualize-4.ll |  6 +-
 llvm/test/Transforms/InstCombine/fmul.ll  |  4 +-
 .../Transforms/InstSimplify/ConstProp/gep.ll  | 12 +--
 .../Internalize/vcall-visibility.ll   |  2 +-
 llvm/test/Transforms/MergeFunc/constexpr.ll   |  8 +-
 .../ThinLTOBitcodeWriter/pr33536.ll   |  2 +-
 41 files changed, 357 insertions(+), 225 deletions(-)

diff --git a/clang/lib/CodeGen/CGVTT.cpp b/clang/lib/CodeGen/CGVTT.cpp
index 1d3f14f1c5344d..e45f6167a94ca2 100644
--- a/clang/lib/CodeGen/CGVTT.cpp
+++ b/clang/lib/CodeGen/CGVTT.cpp
@@ -77,9 +77,19 @@ CodeGenVTables::EmitVTTDefinition(llvm::GlobalVariable *VTT,
llvm::ConstantInt::get(CGM.Int32Ty, AddressPoint.AddressPointIndex),
  };
 
+ // Add inrange attribute to indicate that only the VTableIndex can be
+ // accessed.
+ unsigned ComponentSize =
+ CGM.getDataLayout().getTypeAllocSize(getVTableComponentType());
+ unsigned VTableSize = CGM.getDataLayout().getTypeAllocSize(
+ cast(VTable->getValueType())
+ ->getElementType(AddressPoint.VTableIndex));
+ unsigned Offset = ComponentSize * AddressPoint.AddressPointIndex;
+ llvm::ConstantRange InRange(
+ llvm::APInt(32, -Offset, true),
+ llvm::APInt(32, VTableSize - Offset, true));
  llvm::Constant *Init = llvm::ConstantExpr::getGetElementPtr(
- VTable->getValueType(), VTable, Idxs, /*InBounds=*/true,
- /*InRangeIndex=*/1);
+ VTable->getValueType(), VTable, Idxs, /*InBounds=*/true, InRange);
 
  VTTComponents.push_back(Init);
   }
diff --git a/clang/lib/CodeGen/ItaniumCXXABI.cpp 
b/clang/lib/CodeGen/ItaniumCXXABI.cpp
index 60b45ee78d9316..eb81787b7daa9d 100644
--- a/clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ b/clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -1885,19 +1885,28 @@ ItaniumCXXABI::getVTableAddressPoint(BaseSubobject Base,
 
   // Find 

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

[Nikita Popov via cfe-commits]

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/listinfo/cfe-commits

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

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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?

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

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

[Nikita Popov via cfe-commits]

@@ -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=ArmPL -mllvm 
-force-vector-interleave=1 -mllvm 
-prefer-predicate-over-epilogue=predicate-dont-vectorize -emit-llvm -S -o - %s 
| FileCheck %s
+
+// REQUIRES: aarch64-registered-target
+
+/*
+Testing vectorization of math functions that have the attribute write-only to
+memory set. Given they have vectorized counterparts, they should be able to
+vectorize.
+*/
+
+// The following define is required to access some math functions.
+#define _GNU_SOURCE
+#include 
+
+// frexp/frexpf have no TLI mappings yet.
+
+// CHECK-LABEL: define dso_local void @frexp_f64(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0:[0-9]+]] {
+// CHECK:[[CALL:%.*]] = tail call double @frexp(double noundef 
[[TMP0:%.*]], ptr noundef [[ADD_PTR:%.*]]) #[[ATTR2:[0-9]+]]
+//
+void frexp_f64(double *in, double *out1, int *out2, int N) {
+  for (int i = 0; i < N; ++i)
+*out1 = frexp(in[i], out2+i);
+}
+
+// CHECK-LABEL: define dso_local void @frexp_f32(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0]] {
+// CHECK:[[CALL:%.*]] = tail call float @frexpf(float noundef 
[[TMP0:%.*]], ptr noundef [[ADD_PTR:%.*]]) #[[ATTR2]]
+//
+void frexp_f32(float *in, float *out1, int *out2, int N) {
+  for (int i = 0; i < N; ++i)
+*out1 = frexpf(in[i], out2+i);
+}
+
+// CHECK-LABEL: define dso_local void @modf_f64(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0]] {
+// CHECK:[[CALL:%.*]] = tail call double @modf(double noundef 
[[TMP0:%.*]], ptr noundef [[ADD_PTR:%.*]]) #[[ATTR3:[0-9]+]]
+//
+void modf_f64(double *in, double *out1, double *out2, int N) {
+  for (int i = 0; i < N; ++i)
+  out1[i] = modf(in[i], out2+i);
+}
+
+// CHECK-LABEL: define dso_local void @modf_f32(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0]] {
+// CHECK:[[CALL:%.*]] = tail call float @modff(float noundef [[TMP0:%.*]], 
ptr noundef [[ADD_PTR:%.*]]) #[[ATTR4:[0-9]+]]
+//
+void modf_f32(float *in, float *out1, float *out2, int N) {
+  for (int i = 0; i < N; ++i)
+  out1[i] = modff(in[i], out2+i);
+}

nikic wrote:

This test needs to be in either `llvm/test/Transforms/LoopVectorize` or 
`llvm/test/Analysis/LoopAccessAnalysis`, depending on what exactly you want to 
test.

I don't really get what this test is checking for though, it doesn't look like 
anything was actually vectorized?

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

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

[Nikita Popov via cfe-commits]

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-commits

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

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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">, Visibility<[ClangOption, CC1Option]>;
-defm reroll_loops : BoolFOption<"reroll-loops",
-  CodeGenOpts<"RerollLoops">, DefaultFalse,
-  PosFlag,
-  NegFlag>;

nikic wrote:

Yes, the documentation is generated from Options.td.

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)

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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 9243af902d0fbb44009ac0c1a45fa05826a8d7f4 Mon Sep 17 00:00:00 2001
From: Nikita Popov 
Date: Mon, 19 Feb 2024 16:12:56 +0100
Subject: [PATCH] [Driver] Remove dead -freroll-loops flag

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.
---
 clang/docs/ReleaseNotes.rst   | 2 ++
 clang/include/clang/Driver/Options.td | 4 
 clang/lib/Driver/ToolChains/Clang.cpp | 5 -
 clang/test/Driver/clang_f_opts.c  | 7 ---
 4 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 45ace4191592d3..3093e903410540 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -167,6 +167,8 @@ Modified Compiler Flags
 Removed Compiler Flags
 -
 
+- The ``-freroll-loops`` flag has been removed. It had no effect since Clang 
13.
+
 Attribute Changes in Clang
 --
 
diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 53f23f9abb4c96..36a42b1b050c23 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -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<[ClangOption, CC1Option]>;
-defm reroll_loops : BoolFOption<"reroll-loops",
-  CodeGenOpts<"RerollLoops">, DefaultFalse,
-  PosFlag,
-  NegFlag>;
 def ffinite_loops: Flag<["-"],  "ffinite-loops">, Group,
   HelpText<"Assume all loops are finite.">, Visibility<[ClangOption, 
CC1Option]>;
 def fno_finite_loops: Flag<["-"], "fno-finite-loops">, Group,
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 47305f798c5fee..7daf945ae12712 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -6660,11 +6660,6 @@ void Clang::ConstructJob(Compilation , const JobAction 
,
   CmdArgs.push_back("-fwrapv");
   }
 
-  if (Arg *A = Args.getLastArg(options::OPT_freroll_loops,
-   options::OPT_fno_reroll_loops))
-if (A->getOption().matches(options::OPT_freroll_loops))
-  CmdArgs.push_back("-freroll-loops");
-
   Args.AddLastArg(CmdArgs, options::OPT_ffinite_loops,
   options::OPT_fno_finite_loops);
 
diff --git a/clang/test/Driver/clang_f_opts.c b/clang/test/Driver/clang_f_opts.c
index 33e4aa8386c3b3..472d0725a79340 100644
--- a/clang/test/Driver/clang_f_opts.c
+++ b/clang/test/Driver/clang_f_opts.c
@@ -45,13 +45,6 @@
 // CHECK-UNROLL-LOOPS: "-funroll-loops"
 // CHECK-NO-UNROLL-LOOPS: "-fno-unroll-loops"
 
-// RUN: %clang -### -S -freroll-loops %s 2>&1 | FileCheck 
-check-prefix=CHECK-REROLL-LOOPS %s
-// RUN: %clang -### -S -fno-reroll-loops %s 2>&1 | FileCheck 
-check-prefix=CHECK-NO-REROLL-LOOPS %s
-// RUN: %clang -### -S -fno-reroll-loops -freroll-loops %s 2>&1 | FileCheck 
-check-prefix=CHECK-REROLL-LOOPS %s
-// RUN: %clang -### -S -freroll-loops -fno-reroll-loops %s 2>&1 | FileCheck 
-check-prefix=CHECK-NO-REROLL-LOOPS %s
-// CHECK-REROLL-LOOPS: "-freroll-loops"
-// CHECK-NO-REROLL-LOOPS-NOT: "-freroll-loops"
-
 // RUN: %clang -### -S -fprofile-sample-accurate %s 2>&1 | FileCheck 
-check-prefix=CHECK-PROFILE-SAMPLE-ACCURATE %s
 // CHECK-PROFILE-SAMPLE-ACCURATE: "-fprofile-sample-accurate"
 

___
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)

[Nikita Popov via cfe-commits]

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 `i129` 
> that loads 4 bytes, then even if the last byte is ignored, simply attempting 
> to load it may access memory out of bounds and crash the program. Storing 
> `i129`, it would clobber the next byte of memory.

At least that shouldn't be a problem: LLVM has separate concepts of "store 
size" and "alloc size" where only the latter rounds up to alignment. So `load 
i129` is specified to access only 9 bytes, not 16 bytes.

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)

[Nikita Popov via cfe-commits]

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 doesn't do 
everything that's necessary for that now, such as emitting GEPs in canonical i8 
form with explicitly LLVM-independent offset calculation.

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)

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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 description very vague. Please be more specific about which ICEs 
and miscompilations you are concerned about (godbolt please). Is this *just* 
about the open alignment question, or also something else?

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] [Clang][CodeGen] Loose the cast check when emitting builtins (PR #81669)

[Nikita Popov via cfe-commits]

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
  /// same size only where no re-interpretation of the bits is done.
```
A cast between float and int sounds like "re-interpretation of the bits" to me. 
Though the function already allows it if it's a vector of int/float.

TBH I don't really understand what the purpose of this function is. One of the 
main uses seems to be to restrict what the `returned` attribute can be used 
for, but in that case we probably should stop accepting casts at all -- these 
don't really seem useful, and we've had crashes/miscompiles due to allowing 
them in the past.

For the purposes of this specific change, I think that just dropping the assert 
is indeed the right thing to do. The cast in the bitcast itself is sufficient.

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

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

[Nikita Popov via cfe-commits]

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/listinfo/cfe-commits

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

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via 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 InstCombine itself that 
converts `load(c ? p1 : p2)` into `c ? load(p1) : load(p2)` in 
https://github.com/llvm/llvm-project/blob/141de749597c7b59ebe2c4aa7ee573d124dc903c/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp#L1068-L1087.
 So supporting additional patterns there might be a possible alternative. But I 
think we should try making SROA more powerful first.

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] [Clang][CodeGen] Mark `__dynamic_cast` as `willreturn` (PR #80409)

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via cfe-commits]

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/cgi-bin/mailman/listinfo/cfe-commits

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

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via cfe-commits]

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
 first merged PR from a new contributor

This change adds a comment to the first PR from a new contributor that is 
merged,
which tells them what to expect post merge from the build bots.

How they will be notified, where to ask questions, that you're more likely
to be reverted than in other projects, etc.

To do this, I have added a hidden HTML comment to the new contributor greeting 
comment.
This workflow will look for that to tell if the author of the PR was
a new contributor at the time they opened the merge.

It has to be done this way because as soon as the PR is merged, they are
by GitHub's definition no longer a new contributor and I suspect that
their author assocication will be "contributor" instead.

I cannot 100% confirm that without a whole lot of effort and probably breaking
GitHub's terms of service, but it's fairly cheap to work around anyway.

It seems rare / almost impossible to reopen a PR in llvm at least, but
in case it does happen the buildbot info comment has its own hidden
HTML comment. If we find this we will not post another copy of the
same information.

An example PR can be found here: 
https://github.com/DavidSpickett/llvm-project/pull/84
(exact text content subject to change)
---
 .github/workflows/merged-prs.yml| 36 +++
 llvm/utils/git/github-automation.py | 71 +
 2 files changed, 107 insertions(+)
 create mode 100644 .github/workflows/merged-prs.yml

diff --git a/.github/workflows/merged-prs.yml b/.github/workflows/merged-prs.yml
new file mode 100644
index 0..1b1503610dac1
--- /dev/null
+++ b/.github/workflows/merged-prs.yml
@@ -0,0 +1,36 @@
+name: "Add buildbot information to first PRs from new contributors"
+
+permissions:
+  contents: read
+
+on:
+  # It's safe to use pull_request_target here, because we aren't checking out
+  # code from the pull request branch.
+  # See 
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
+  pull_request_target:
+types:
+  - closed
+
+jobs:
+  buildbot_comment:
+runs-on: ubuntu-latest
+permissions:
+  pull-requests: write
+if: >-
+  (github.repository == 'llvm/llvm-project') &&
+  (github.event.pull_request.merged == true)
+steps:
+  - name: Setup Automation Script
+run: |
+  curl -O -L --fail 
https://raw.githubusercontent.com/"$GITHUB_REPOSITORY"/main/llvm/utils/git/github-automation.py
+  curl -O -L --fail 
https://raw.githubusercontent.com/"$GITHUB_REPOSITORY"/main/llvm/utils/git/requirements.txt
+  chmod a+x github-automation.py
+  pip install -r requirements.txt
+
+  - name: Add Buildbot information comment
+run: |
+  ./github-automation.py \
+--token '${{ secrets.GITHUB_TOKEN }}' \
+pr-buildbot-information \
+--issue-number "${{ github.event.pull_request.number }}" \
+--author "${{ github.event.pull_request.user.login }}"
diff --git a/llvm/utils/git/github-automation.py 
b/llvm/utils/git/github-automation.py
index f78d91059ecd3..55659679536f4 100755
--- a/llvm/utils/git/github-automation.py
+++ b/llvm/utils/git/github-automation.py
@@ -208,6 +208,8 @@ def _get_curent_team(self) -> Optional[github.Team.Team]:
 
 
 class PRGreeter:
+COMMENT_TAG = "\n"
+
 def __init__(self, token: str, repo: str, pr_number: int):
 repo = github.Github(token).get_repo(repo)
 self.pr = repo.get_issue(pr_number).as_pull_request()
@@ -217,7 +219,9 @@ def run(self) -> bool:
 # by a user new to LLVM and/or GitHub itself.
 
 # This text is using Markdown formatting.
+
 comment = f"""\
+{PRGreeter.COMMENT_TAG}
 Thank you for submitting a Pull Request (PR) to the LLVM Project!
 
 This PR will be automatically labeled and the relevant teams will be
@@ -240,6 +244,64 @@ def run(self) -> bool:
 return True
 
 
+class PRBuildbotInformation:
+COMMENT_TAG = "\n"
+
+def __init__(self, token: str, repo: str, pr_number: int, author: str):
+repo = github.Github(token).get_repo(repo)
+self.pr = repo.get_issue(pr_number).as_pull_request()
+self.author = author
+
+def should_comment(self) -> bool:
+# As soon as a new contributor has a PR merged, they are no longer a 
new contributor.
+# We can tell that they were a new contributor previously because we 
would have
+# added a new contributor greeting comment when they opened the PR.
+found_greeting = False
+for comment in self.pr.as_issue().get_comments():
+if PRGreeter.COMMENT_TAG in comment.body:
+found_greeting = True
+elif 

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

[Nikita Popov via cfe-commits]

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 that pcm -- that'd be the 
> behavior if we used header files instead of a module.

The pcm here is being generated by clang, not by clang-repl, so I'm not sure 
how we would know that we need to switch the triple.

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

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

[Nikita Popov via cfe-commits]

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)

[Nikita Popov via cfe-commits]

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: 
https://github.com/llvm/llvm-project/blob/754a8add57098ef71e4a51a9caa0cc175e94377d/clang/lib/Interpreter/Interpreter.cpp#L165-L166

getProcessTriple() is based on LLVM_HOST_TRIPLE with some fixups.

I'm not really sure what the right fix here is. It makes sense that an 
interpreter uses the host triple by default, but it's also a problem that clang 
and clang-repl use different default triples.

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

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

[Nikita Popov via cfe-commits]

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 target 
feature is passed, and a codegen test that uses cc1.

>From c44059be08fa08ef09498bfd7193ac7d52680e18 Mon Sep 17 00:00:00 2001
From: Nikita Popov 
Date: Mon, 29 Jan 2024 12:12:41 +0100
Subject: [PATCH] [Clang, SystemZ] Split test into Driver and CodeGen parts
 (NFC)

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 tests into two, a driver test that checks that the
appropriate target feature is passed, and a codegen test that uses
cc1.
---
 clang/test/CodeGen/SystemZ/unaligned-symbols.c | 11 ---
 clang/test/Driver/s390x-unaligned-symbols.c|  7 +++
 2 files changed, 11 insertions(+), 7 deletions(-)
 create mode 100644 clang/test/Driver/s390x-unaligned-symbols.c

diff --git a/clang/test/CodeGen/SystemZ/unaligned-symbols.c 
b/clang/test/CodeGen/SystemZ/unaligned-symbols.c
index 31fc211393dd719..b19f30338857992 100644
--- a/clang/test/CodeGen/SystemZ/unaligned-symbols.c
+++ b/clang/test/CodeGen/SystemZ/unaligned-symbols.c
@@ -1,13 +1,10 @@
-// RUN: %clang -target s390x-linux-gnu %s -o - -emit-llvm -S \
+// RUN: %clang_cc1 -triple s390x-linux-gnu %s -o - -emit-llvm \
 // RUN:| FileCheck %s -check-prefixes=CHECK,ALIGNED
 
-// RUN: %clang -target s390x-linux-gnu %s -o - -emit-llvm -S \
-// RUN:-mno-unaligned-symbols | FileCheck %s -check-prefixes=CHECK,ALIGNED
+// RUN: %clang_cc1 -triple s390x-linux-gnu %s -o - -emit-llvm \
+// RUN:-target-feature -unaligned-symbols | FileCheck %s 
-check-prefixes=CHECK,ALIGNED
 
-// RUN: %clang -target s390x-linux-gnu %s -o - -emit-llvm -S \
-// RUN:-munaligned-symbols | FileCheck %s -check-prefixes=CHECK,UNALIGN
-
-// RUN: %clang -cc1 -triple s390x-linux-gnu %s -o - -emit-llvm \
+// RUN: %clang_cc1 -triple s390x-linux-gnu %s -o - -emit-llvm \
 // RUN:-target-feature +unaligned-symbols | FileCheck %s 
-check-prefixes=CHECK,UNALIGN
 
 
diff --git a/clang/test/Driver/s390x-unaligned-symbols.c 
b/clang/test/Driver/s390x-unaligned-symbols.c
new file mode 100644
index 000..1dff5b737fff776
--- /dev/null
+++ b/clang/test/Driver/s390x-unaligned-symbols.c
@@ -0,0 +1,7 @@
+// RUN: %clang -target s390x-linux-gnu -### -c %s 2>&1 | FileCheck 
-check-prefix=DEFAULT %s
+// RUN: %clang -target s390x-linux-gnu -mno-unaligned-symbols -### -c %s 2>&1 
| FileCheck -check-prefix=ALIGNED %s
+// RUN: %clang -target s390x-linux-gnu -munaligned-symbols -### -c %s 2>&1 | 
FileCheck -check-prefix=UNALIGN %s
+
+// DEFAULT-NOT: unaligned-symbols"
+// ALIGNED: "-target-feature" "-unaligned-symbols"
+// UNALIGN: "-target-feature" "+unaligned-symbols"

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits