Re: [PATCH] D37826: Refine generation of TBAA information in clang

2017-09-28 Thread Ivan Kosarev via cfe-commits
Thanks for the ack Daniel. Hopefully others will eventually have a 
chance to review.


On 27/09/17 19:00, Daniel Berlin wrote:

(As i mentioned to hal offline, i'm too slammed to help here)

On Wed, Sep 27, 2017 at 8:47 AM, Ivan A. Kosarev via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:


kosarev added a comment.

Colleagues, please let me know if I can do anything else to help
with reviewing the patch. Thanks.


https://reviews.llvm.org/D37826 






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


Re: r315984 - [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info

2017-10-18 Thread Ivan Kosarev via cfe-commits

Hello Douglas,

Sure, I'm on it. Thanks for reporting and sorry for the troubles.


On 18/10/17 20:24, Yung, Douglas wrote:

Hi Ivan,

This change caused a compiler crash in one of our tests. I have put the details 
in PR34992, can you take a look?

Douglas Yung


-Original Message-
From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
Ivan A. Kosarev via cfe-commits
Sent: Tuesday, October 17, 2017 2:12
To: cfe-commits@lists.llvm.org
Subject: r315984 - [CodeGen] EmitPointerWithAlignment() to generate TBAA info
along with LValue base info

Author: kosarev
Date: Tue Oct 17 02:12:13 2017
New Revision: 315984

URL: http://llvm.org/viewvc/llvm-project?rev=315984&view=rev
Log:
[CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue
base info

Differential Revision: https://reviews.llvm.org/D38796

Added:
 cfe/trunk/test/CodeGen/tbaa-cast.cpp
Modified:
 cfe/trunk/lib/CodeGen/CGExpr.cpp
 cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
 cfe/trunk/lib/CodeGen/CodeGenFunction.h
 cfe/trunk/lib/CodeGen/CodeGenModule.cpp
 cfe/trunk/lib/CodeGen/CodeGenModule.h
 cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
 cfe/trunk/lib/CodeGen/CodeGenTBAA.h

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=315984&r1=315983&r2=315984&view=d
iff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Tue Oct 17 02:12:13 2017
@@ -916,7 +916,8 @@ void CodeGenModule::EmitExplicitCastExpr
  /// EmitPointerWithAlignment - Given an expression of pointer type, try to
/// derive a more accurate bound on the alignment of the pointer.
  Address CodeGenFunction::EmitPointerWithAlignment(const Expr *E,
-  LValueBaseInfo *BaseInfo) {
+  LValueBaseInfo *BaseInfo,
+  TBAAAccessInfo
+ *TBAAInfo) {
// We allow this with ObjC object pointers because of fragile ABIs.
assert(E->getType()->isPointerType() ||
   E->getType()->isObjCObjectPointerType());
@@ -936,20 +937,30 @@ Address CodeGenFunction::EmitPointerWith
  if (PtrTy->getPointeeType()->isVoidType())
break;

-LValueBaseInfo InnerInfo;
-Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
&InnerInfo);
-if (BaseInfo) *BaseInfo = InnerInfo;
-
-// If this is an explicit bitcast, and the source l-value is
-// opaque, honor the alignment of the casted-to type.
-if (isa(CE) &&
-InnerInfo.getAlignmentSource() != AlignmentSource::Decl) {
-  LValueBaseInfo ExpInfo;
+LValueBaseInfo InnerBaseInfo;
+TBAAAccessInfo InnerTBAAInfo;
+Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
+&InnerBaseInfo,
+&InnerTBAAInfo);
+if (BaseInfo) *BaseInfo = InnerBaseInfo;
+if (TBAAInfo) *TBAAInfo = InnerTBAAInfo;
+
+if (isa(CE)) {
+  LValueBaseInfo TargetTypeBaseInfo;
+  TBAAAccessInfo TargetTypeTBAAInfo;
CharUnits Align = getNaturalPointeeTypeAlignment(E->getType(),
-   &ExpInfo);
-  if (BaseInfo)
-BaseInfo->mergeForCast(ExpInfo);
-  Addr = Address(Addr.getPointer(), Align);
+
&TargetTypeBaseInfo,
+
&TargetTypeTBAAInfo);
+  if (TBAAInfo)
+*TBAAInfo = CGM.mergeTBAAInfoForCast(*TBAAInfo,
+ TargetTypeTBAAInfo);
+  // If the source l-value is opaque, honor the alignment of the
+  // casted-to type.
+  if (InnerBaseInfo.getAlignmentSource() != AlignmentSource::Decl) {
+if (BaseInfo)
+  BaseInfo->mergeForCast(TargetTypeBaseInfo);
+Addr = Address(Addr.getPointer(), Align);
+  }
  }

  if (SanOpts.has(SanitizerKind::CFIUnrelatedCast) && @@ -969,12
+980,13 @@ Address CodeGenFunction::EmitPointerWith

  // Array-to-pointer decay.
  case CK_ArrayToPointerDecay:
-  return EmitArrayToPointerDecay(CE->getSubExpr(), BaseInfo);
+  return EmitArrayToPointerDecay(CE->getSubExpr(), BaseInfo,
+ TBAAInfo);

  // Derived-to-base conversions.
  case CK_UncheckedDerivedToBase:
  case CK_DerivedToBase: {
-  Address Addr = EmitPointerWithAlignment(CE->getSubExpr(), BaseInfo);
+  Address Addr = EmitPointerWithAlignment(CE->getSubExpr(), BaseInfo,
+  TBAAInfo);
auto Derived = CE->getSubExpr()->getType()->getPointeeCXXRecordDecl();
return GetAddressOfBaseClass(Addr, Derived,
 CE->path_begin(), CE->path_end(), @@ -
994,6 +1006,7

Re: r315984 - [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info

2017-12-22 Thread Ivan Kosarev via cfe-commits

Hello Alex,

I'm working on it.

Thanks,


On 22/12/17 00:07, Alex L wrote:

Hi,

This commit has caused a new regression in LLVM 6. I filed the 
following PR: https://bugs.llvm.org/show_bug.cgi?id=35724 .

Could you please take a look?

Thanks,
Alex

On 17 October 2017 at 02:12, Ivan A. Kosarev via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:


Author: kosarev
Date: Tue Oct 17 02:12:13 2017
New Revision: 315984

URL: http://llvm.org/viewvc/llvm-project?rev=315984&view=rev

Log:
[CodeGen] EmitPointerWithAlignment() to generate TBAA info along
with LValue base info

Differential Revision: https://reviews.llvm.org/D38796


Added:
    cfe/trunk/test/CodeGen/tbaa-cast.cpp
Modified:
    cfe/trunk/lib/CodeGen/CGExpr.cpp
    cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
    cfe/trunk/lib/CodeGen/CodeGenFunction.h
    cfe/trunk/lib/CodeGen/CodeGenModule.cpp
    cfe/trunk/lib/CodeGen/CodeGenModule.h
    cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
    cfe/trunk/lib/CodeGen/CodeGenTBAA.h

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=315984&r1=315983&r2=315984&view=diff



==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Tue Oct 17 02:12:13 2017
@@ -916,7 +916,8 @@ void CodeGenModule::EmitExplicitCastExpr
 /// EmitPointerWithAlignment - Given an expression of pointer
type, try to
 /// derive a more accurate bound on the alignment of the pointer.
 Address CodeGenFunction::EmitPointerWithAlignment(const Expr *E,
- LValueBaseInfo *BaseInfo) {
+ LValueBaseInfo *BaseInfo,
+ TBAAAccessInfo *TBAAInfo) {
   // We allow this with ObjC object pointers because of fragile ABIs.
   assert(E->getType()->isPointerType() ||
          E->getType()->isObjCObjectPointerType());
@@ -936,20 +937,30 @@ Address CodeGenFunction::EmitPointerWith
         if (PtrTy->getPointeeType()->isVoidType())
           break;

-        LValueBaseInfo InnerInfo;
-        Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
&InnerInfo);
-        if (BaseInfo) *BaseInfo = InnerInfo;
-
-        // If this is an explicit bitcast, and the source l-value is
-        // opaque, honor the alignment of the casted-to type.
-        if (isa(CE) &&
-            InnerInfo.getAlignmentSource() !=
AlignmentSource::Decl) {
-          LValueBaseInfo ExpInfo;
+        LValueBaseInfo InnerBaseInfo;
+        TBAAAccessInfo InnerTBAAInfo;
+        Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
+ &InnerBaseInfo,
+ &InnerTBAAInfo);
+        if (BaseInfo) *BaseInfo = InnerBaseInfo;
+        if (TBAAInfo) *TBAAInfo = InnerTBAAInfo;
+
+        if (isa(CE)) {
+          LValueBaseInfo TargetTypeBaseInfo;
+          TBAAAccessInfo TargetTypeTBAAInfo;
           CharUnits Align =
getNaturalPointeeTypeAlignment(E->getType(),
-  &ExpInfo);
-          if (BaseInfo)
-            BaseInfo->mergeForCast(ExpInfo);
-          Addr = Address(Addr.getPointer(), Align);
+  &TargetTypeBaseInfo,
+  &TargetTypeTBAAInfo);
+          if (TBAAInfo)
+            *TBAAInfo = CGM.mergeTBAAInfoForCast(*TBAAInfo,
+  TargetTypeTBAAInfo);
+          // If the source l-value is opaque, honor the alignment
of the
+          // casted-to type.
+          if (InnerBaseInfo.getAlignmentSource() !=
AlignmentSource::Decl) {
+            if (BaseInfo)
+              BaseInfo->mergeForCast(TargetTypeBaseInfo);
+            Addr = Address(Addr.getPointer(), Align);
+          }
         }

         if (SanOpts.has(SanitizerKind::CFIUnrelatedCast) &&
@@ -969,12 +980,13 @@ Address CodeGenFunction::EmitPointerWith

     // Array-to-pointer decay.
     case CK_ArrayToPointerDecay:
-      return EmitArrayToPointerDecay(CE->getSubExpr(), BaseInfo);
+      return EmitArrayToPointerDecay(CE->getSubExpr(), BaseInfo,
TBAAInfo);

     // Derived-to-base conversions.
     case CK_UncheckedDerivedToBase:
     case CK_DerivedToBase: {
-      Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
BaseInfo);
+      Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
BaseInfo,
+                                              TBAAInfo);
       auto Derived =
CE->getSubExpr()->getType()->getPointeeCXXRecordDecl();
       return GetAddressOfBaseClass(Addr, Derived,
                                    CE->path_begin(), CE->

[clang] [llvm] [JITLink][RISCV] Implement eh_frame handling (PR #68253)

2024-01-10 Thread Ivan Kosarev via cfe-commits

kosarev wrote:

It seems after this change we started to fail on `LLVM :: 
ExecutionEngine/JITLink/RISCV/ELF_ehframe.s` when using debug libgcxx.

Tagging #68594.

```
/usr/include/c++/11/bits/stl_algo.h:2217:
In function:
std::pair<_FIter, _FIter> std::equal_range(_FIter, _FIter, const _Tp&, 
_Compare) [with _FIter = gnu_debug::_Safe_iterator > >, 
std::debug::vector, 
std::random_access_iterator_tag>; _Tp = long unsigned int; _Compare = 
llvm::jitlink::getRISCVPCRelHi20(const llvm::jitlink::Edge&)::Comp]

Error: elements in iterator range [first, last) are not partitioned by the 
predicate __comp and value __val.

Objects involved in the operation:
iterator "first" @ 0x7ffccd5f47b0 {
  state = dereferenceable (start-of-sequence);
  references sequence @ 0x55c7976a5718
}
iterator "last" @ 0x7ffccd5f47e0 {
  state = past-the-end;
  references sequence @ 0x55c7976a5718
}
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and 
include the crash backtrace.
Stack dump:
0.  Program arguments: 
/home/kosarev/labs/llvm-project/build/debug+expensive_checks/bin/llvm-jitlink 
-noexec -phony-externals -debug-only=jitlink 
/home/kosarev/labs/llvm-project/build/debug+expensive_checks/test/ExecutionEngine/JITLink/RISCV/Output/ELF_ehframe.s.tmp.32.o
 #0 0x7f95fe6db674 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
/home/kosarev/labs/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:22
 #1 0x7f95fe6dba95 PrintStackTraceSignalHandler(void*) 
/home/kosarev/labs/llvm-project/llvm/lib/Support/Unix/Signals.inc:798:1
 #2 0x7f95fe6d8edd llvm::sys::RunSignalHandlers() 
/home/kosarev/labs/llvm-project/llvm/lib/Support/Signals.cpp:105:20
 #3 0x7f95fe6daf0c SignalHandler(int) 
/home/kosarev/labs/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
 #4 0x7f95fdf5c520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #5 0x7f95fdfb09fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #6 0x7f95fdfb09fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
 #7 0x7f95fdfb09fc pthread_kill ./nptl/pthread_kill.c:89:10
 #8 0x7f95fdf5c476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #9 0x7f95fdf427f3 abort ./stdlib/abort.c:81:7
#10 0x7f95fe1e71fb std::__throw_bad_exception() 
(/lib/x86_64-linux-gnu/libstdc++.so.6+0xa51fb)
#11 0x7f95ff75fa4b 
std::pair<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator>>, 
std::__debug::vector>, 
std::random_access_iterator_tag>, 
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator>>, 
std::__debug::vector>, 
std::random_access_iterator_tag>> 
std::equal_range<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator>>, 
std::__debug::vector>, 
std::random_access_iterator_tag>, unsigned long, 
llvm::jitlink::getRISCVPCRelHi20(llvm::jitlink::Edge 
const&)::Comp>(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator>>, 
std::__debug::vector>, 
std::random_access_iterator_tag>, 
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator>>, 
std::__debug::vector>, 
std::random_access_iterator_tag>, unsigned long const&, 
llvm::jitlink::getRISCVPCRelHi20(llvm::jitlink::Edge const&)::Comp) 
/usr/include/c++/11/bits/stl_algo.h:2219:7
#12 0x7f95ff75cf94 llvm::jitlink::getRISCVPCRelHi20(llvm::jitlink::Edge 
const&) 
/home/kosarev/labs/llvm-project/llvm/lib/ExecutionEngine/JITLink/ELF_riscv.cpp:157:74
#13 0x7f95ff766692 
llvm::jitlink::ELFJITLinker_riscv::applyFixup(llvm::jitlink::LinkGraph&, 
llvm::jitlink::Block&, llvm::jitlink::Edge const&) const 
/home/kosarev/labs/llvm-project/llvm/lib/ExecutionEngine/JITLink/ELF_riscv.cpp:273:12
#14 0x7f95ff770ce5 
llvm::jitlink::JITLinker::fixUpBlocks(llvm::jitlink::LinkGraph&)
 const 
/home/kosarev/labs/llvm-project/llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.h:171:11
#15 0x7f95ff67f0d7 
llvm::jitlink::JITLinkerBase::linkPhase3(std::unique_ptr>, 
llvm::Expected, 
llvm::detail::DenseMapPair>>) 
/home/kosarev/labs/llvm-project/llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.cpp:163:33
#16 0x7f95ff67e586 
llvm::jitlink::JITLinkerBase::linkPhase2(std::unique_ptr>, 
llvm::Expected>>)::'lambda'(llvm::Expected, 
llvm::detail::DenseMapPair>>)::operator()(llvm::Expected, 
llvm::detail::DenseMapPair>>) 
/home/kosarev/labs/llvm-project/llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.cpp:130:39
#17 0x7f95ff680f39 
std::unique_ptr> 
llvm::jitlink::createLookupContinuation>, 
llvm::Expected>>)::'lambda'(llvm::Expected, 
llvm::detail::DenseMapPair>>)>(llvm::jitlink::JITLinkerBase::linkPhase2(std::unique_ptr>, 
llvm::Expected>>)::'lambda'(llvm::Expected, 
llvm::detail::DenseMapPair>>))::Impl::run(llvm::Expected, 
llvm::detail::DenseMapPair>>) 
/home/kosarev/labs/llvm-project/llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h:1780:58
#18 0x7f9601034f75 
llvm::orc::ObjectLinkingLayerJITLinkContext::lookup(llvm::DenseMap, 
llvm::detail::DenseMapPair> 
const&, std::unique_ptr>)::'lambda0'(llvm::Expected, llvm::detail:

[clang] be4eaf1 - [Clang][CodeGen] Fix the cmse-clear-return.c test.

2022-05-24 Thread Ivan Kosarev via cfe-commits

Author: Ivan Kosarev
Date: 2022-05-24T12:49:42+01:00
New Revision: be4eaf10eef76869eb404f68703a1a09b344a7e5

URL: 
https://github.com/llvm/llvm-project/commit/be4eaf10eef76869eb404f68703a1a09b344a7e5
DIFF: 
https://github.com/llvm/llvm-project/commit/be4eaf10eef76869eb404f68703a1a09b344a7e5.diff

LOG: [Clang][CodeGen] Fix the cmse-clear-return.c test.

Caught with D125604.

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D126191

Added: 


Modified: 
clang/test/CodeGen/cmse-clear-return.c

Removed: 




diff  --git a/clang/test/CodeGen/cmse-clear-return.c 
b/clang/test/CodeGen/cmse-clear-return.c
index 791f485859f32..158b545159427 100644
--- a/clang/test/CodeGen/cmse-clear-return.c
+++ b/clang/test/CodeGen/cmse-clear-return.c
@@ -228,11 +228,12 @@ typedef struct __attribute__((packed)) T14 {
 
 T14 t14;
 __attribute__((cmse_nonsecure_entry)) T14 f14(void) { return t14; }
-// CHECK: define {{.*}} @f14()
-// CHECK: [[R:%.*]] = load
-// CHECK-LE-NOPT-NEXT: [[AND:%.+]] = and i32 [[R]], -1
-// CHECK-BE-NOPT-NEXT: [[AND:%.+]] = and i32 [[R]], -1
-// CHECK_NEXT: ret i32 [[AND]]
+// CHECK: define {{.*}} @f14()
+// CHECK: [[R:%.*]] = load
+// CHECK-LE-OPT:  ret i32 [[R]]
+// CHECK-LE-NOPT: [[AND:%.+]] = and i32 [[R]], -1
+// CHECK-LE-NOPT: ret i32 [[AND]]
+// CHECK-BE-OPT:  ret i32 [[R]]
 
 // LE: ..11 ..11   0xf3f3/-3085
 // BE: 11.. 11..   0xcfcf/-808452097



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


[clang] [libcxx] [llvm] [libunwind] [libc] [lldb] [compiler-rt] [lld] [clang-tools-extra] [flang] [AMDGPU] Fix predicates for V_DOT instructions. (PR #78198)

2024-01-16 Thread Ivan Kosarev via cfe-commits

https://github.com/kosarev updated 
https://github.com/llvm/llvm-project/pull/78198

>From 0dc06c5ab3b1ff5f2441ff0ee26f5a6dfbbb7753 Mon Sep 17 00:00:00 2001
From: Ivan Kosarev 
Date: Mon, 15 Jan 2024 17:20:34 +
Subject: [PATCH] [AMDGPU] Fix predicates for V_DOT instructions.

Resolves AsmParser ambiguities, e.g., between V_DOT4C_I32_I8_dpp_vi and
V_DOT4C_I32_I8_dpp_gfx10. The latter is predicated with isGFX10Only while
the first has no subtarget generation predicates.

Part of .
---
 llvm/lib/Target/AMDGPU/VOP2Instructions.td | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/llvm/lib/Target/AMDGPU/VOP2Instructions.td 
b/llvm/lib/Target/AMDGPU/VOP2Instructions.td
index 48d4e259bc1cec..bbb2ac0bdb861d 100644
--- a/llvm/lib/Target/AMDGPU/VOP2Instructions.td
+++ b/llvm/lib/Target/AMDGPU/VOP2Instructions.td
@@ -2512,6 +2512,7 @@ defm V_FMAAK_F32: VOP2_Real_MADK_gfx940 <0x18>;
 }
 
 multiclass VOP2_Real_DOT_ACC_gfx9 op> : Base_VOP2_Real_e32e64_vi {
+  let SubtargetPredicate = isGFX9Only in
   def _dpp_vi : VOP2_DPP(NAME#"_dpp")>;
 }
 
@@ -2520,22 +2521,22 @@ multiclass VOP2_Real_DOT_ACC_gfx10 op> :
   VOP2_Real_dpp_gfx10,
   VOP2_Real_dpp8_gfx10;
 
-let SubtargetPredicate = HasDot5Insts in {
+let OtherPredicates = [HasDot5Insts] in {
   defm V_DOT2C_F32_F16 : VOP2_Real_DOT_ACC_gfx9<0x37>;
   // NB: Opcode conflicts with V_DOT8C_I32_I4
   // This opcode exists in gfx 10.1* only
   defm V_DOT2C_F32_F16 : VOP2_Real_DOT_ACC_gfx10<0x02>;
 }
 
-let SubtargetPredicate = HasDot6Insts in {
+let OtherPredicates = [HasDot6Insts] in {
   defm V_DOT4C_I32_I8  : VOP2_Real_DOT_ACC_gfx9<0x39>;
   defm V_DOT4C_I32_I8  : VOP2_Real_DOT_ACC_gfx10<0x0d>;
 }
 
-let SubtargetPredicate = HasDot4Insts in {
+let OtherPredicates = [HasDot4Insts] in {
   defm V_DOT2C_I32_I16 : VOP2_Real_DOT_ACC_gfx9<0x38>;
 }
-let SubtargetPredicate = HasDot3Insts in {
+let OtherPredicates = [HasDot3Insts] in {
   defm V_DOT8C_I32_I4  : VOP2_Real_DOT_ACC_gfx9<0x3a>;
 }
 

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


[clang-tools-extra] [libcxx] [clang] [lldb] [lld] [llvm] [flang] [libc] [compiler-rt] [AMDGPU][GFX12] VOP encoding and codegen - add support for v_cvt fp8/… (PR #78414)

2024-01-22 Thread Ivan Kosarev via cfe-commits

kosarev wrote:

> Correct, some of these instructions use opsel[1] which in LLVM in stored in 
> src1_modifiers so a dummy src1 is used.

Why can't we just use `SRCMODS.OP_SEL_1` with src0?

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


[libcxx] [lld] [libc] [lldb] [clang] [flang] [compiler-rt] [clang-tools-extra] [llvm] [AMDGPU][GFX12] VOP encoding and codegen - add support for v_cvt fp8/… (PR #78414)

2024-01-22 Thread Ivan Kosarev via cfe-commits


@@ -626,11 +629,82 @@ class Cvt_PK_F32_F8_Pat;
 
-foreach Index = [0, -1] in {
-  def : Cvt_PK_F32_F8_Pat;
-  def : Cvt_PK_F32_F8_Pat;
+let SubtargetPredicate = isGFX9Only in {
+  foreach Index = [0, -1] in {
+def : Cvt_PK_F32_F8_Pat;
+def : Cvt_PK_F32_F8_Pat;
+  }
+}
+
+
+// Similar to VOPProfile_Base_CVT_F32_F8, but for VOP3 instructions.
+def VOPProfile_Base_CVT_PK_F32_F8_OpSel : VOPProfileI2F  {
+  let InsVOP3OpSel = (ins Src0Mod:$src0_modifiers, Src0RC64:$src0,
+  clampmod:$clamp, omod:$omod, op_sel0:$op_sel);
+
+  let HasOpSel = 1;
+  let HasExtVOP3DPP = 0;
+}
+
+def VOPProfile_Base_CVT_F32_F8_OpSel : VOPProfile<[f32, i32, i32, untyped]> {
+  let InsVOP3OpSel = (ins Src0Mod:$src0_modifiers, Src0RC64:$src0,
+  Src1Mod:$src1_modifiers, Src1RC64:$src1,
+  clampmod:$clamp, omod:$omod, op_sel0:$op_sel);
+  let AsmVOP3OpSel = !subst(", $src1_modifiers", "", getAsmVOP3OpSel<2, 0, 0, 
1, 1, 0>.ret);
+
+  let HasOpSel = 1;
+  let HasExtDPP = 1;
+  let HasExtVOP3DPP = 1;
+
+  let Src1VOP3DPP = Src1RC64;
+  let AsmVOP3DPP8 = getAsmVOP3DPP8.ret;
+  let AsmVOP3DPP16 = getAsmVOP3DPP16.ret;
+}
+
+let SubtargetPredicate = isGFX12Plus, mayRaiseFPException = 0,
+SchedRW = [WriteFloatCvt] in {
+  defm V_CVT_F32_FP8_OP_SEL: VOP1Inst<"v_cvt_f32_fp8_op_sel", 
VOPProfile_Base_CVT_F32_F8_OpSel>;
+  defm V_CVT_F32_BF8_OP_SEL: VOP1Inst<"v_cvt_f32_bf8_op_sel", 
VOPProfile_Base_CVT_F32_F8_OpSel>;
+  defm V_CVT_PK_F32_FP8_OP_SEL : VOP1Inst<"v_cvt_pk_f32_fp8_op_sel", 
VOPProfile_Base_CVT_PK_F32_F8_OpSel>;
+  defm V_CVT_PK_F32_BF8_OP_SEL : VOP1Inst<"v_cvt_pk_f32_bf8_op_sel", 
VOPProfile_Base_CVT_PK_F32_F8_OpSel>;
+}
+
+class Cvt_F32_F8_Pat_OpSel index,
+VOP1_Pseudo inst_e32, VOP3_Pseudo inst_e64> : GCNPat<
+(f32 (node i32:$src, index)),
+!if (index,
+ (inst_e64 !if(index{0}, SRCMODS.OP_SEL_0, SRCMODS.OP_SEL_1), $src,
+   !if(index{1}, SRCMODS.OP_SEL_0, SRCMODS.OP_SEL_1), (i32 0),

kosarev wrote:

Why do we expect `SRCMODS.OP_SEL_1` for dropped index bits? Is there any test 
coverage for these cases?

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


[clang] [libcxx] [libc] [lld] [llvm] [flang] [clang-tools-extra] [lldb] [compiler-rt] [AMDGPU][GFX12] VOP encoding and codegen - add support for v_cvt fp8/… (PR #78414)

2024-01-22 Thread Ivan Kosarev via cfe-commits
Mirko =?utf-8?q?Brkušanin?= 
Message-ID:
In-Reply-To: 



@@ -305,6 +305,11 @@ class VOP3OpSel_gfx10 op, VOPProfile p> : 
VOP3e_gfx10 {
 
 class VOP3OpSel_gfx11_gfx12 op, VOPProfile p> : VOP3OpSel_gfx10;
 
+class VOP3FP8OpSel_gfx11_gfx12 op, VOPProfile p> : VOP3e_gfx10 
{
+  let Inst{11} = !if(p.HasSrc0, src0_modifiers{2}, 0);
+  let Inst{12} = !if(p.HasSrc0, src0_modifiers{3}, 0);

kosarev wrote:

Yes, thanks Mirko. Can we also avoid adding the other dummy operands in 
`cvtVOP3DPP()` and `cvtDPP()`?

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


[clang] ad1d60c - [FileCheck] Catch missspelled directives.

2022-05-26 Thread Ivan Kosarev via cfe-commits

Author: Ivan Kosarev
Date: 2022-05-26T11:37:19+01:00
New Revision: ad1d60c3befd606d6864b367f939238e50fb0f7e

URL: 
https://github.com/llvm/llvm-project/commit/ad1d60c3befd606d6864b367f939238e50fb0f7e
DIFF: 
https://github.com/llvm/llvm-project/commit/ad1d60c3befd606d6864b367f939238e50fb0f7e.diff

LOG: [FileCheck] Catch missspelled directives.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D125604

Added: 
llvm/test/FileCheck/missspelled-directive.txt

Modified: 
clang/test/CodeGenCXX/attr-mustprogress.cpp
clang/test/CodeGenCXX/eh-aggregate-copy-destroy.cpp
clang/test/CodeGenCXX/inheriting-constructor.cpp
clang/test/CodeGenObjC/non-runtime-protocol.m
clang/test/OpenMP/master_taskloop_private_codegen.cpp
clang/test/OpenMP/master_taskloop_simd_private_codegen.cpp
clang/test/OpenMP/parallel_master_taskloop_private_codegen.cpp
clang/test/OpenMP/parallel_master_taskloop_simd_private_codegen.cpp
clang/test/OpenMP/task_private_codegen.cpp
clang/test/OpenMP/taskgroup_task_reduction_codegen.cpp
clang/test/OpenMP/taskloop_private_codegen.cpp
clang/test/OpenMP/taskloop_simd_private_codegen.cpp
flang/test/Fir/convert-to-llvm.fir
flang/test/Lower/Intrinsics/not.f90
llvm/include/llvm/FileCheck/FileCheck.h
llvm/lib/FileCheck/FileCheck.cpp
llvm/test/Analysis/MemorySSA/phi-translation.ll
llvm/test/Analysis/RegionInfo/infinite_loop_4.ll
llvm/test/CodeGen/AMDGPU/divergence-driven-bfe-isel.ll
llvm/test/CodeGen/AMDGPU/hoist-cond.ll
llvm/test/CodeGen/AMDGPU/llvm.amdgcn.ps.live.ll
llvm/test/CodeGen/AMDGPU/mode-register.mir
llvm/test/CodeGen/AMDGPU/smrd.ll
llvm/test/CodeGen/ARM/cmpxchg-O0-be.ll
llvm/test/CodeGen/AVR/atomics/fence.ll
llvm/test/CodeGen/BPF/CORE/offset-reloc-middle-chain.ll
llvm/test/CodeGen/WebAssembly/libcalls.ll
llvm/test/DebugInfo/NVPTX/debug-info.ll
llvm/test/MC/AMDGPU/data.s
llvm/test/MC/AsmParser/directive_file-g.s
llvm/test/MC/PowerPC/ppc64-reloc-directive-pcrel.s
llvm/test/MC/WebAssembly/unnamed-data.ll
llvm/test/Transforms/Inline/inline-strictfp.ll
llvm/test/Transforms/LoopVectorize/X86/gather-vs-interleave.ll
llvm/test/Transforms/MergeFunc/alias.ll
llvm/test/Transforms/PGOProfile/PR41279.ll
llvm/test/Transforms/PGOProfile/memop_clone.ll
llvm/test/Transforms/PGOProfile/memop_size_from_strlen.ll
llvm/test/tools/llvm-dwp/X86/tu_units_v5.s
llvm/test/tools/llvm-dwp/X86/type_dedup_v5.test
llvm/test/tools/llvm-objdump/MachO/disassemble-all.test
llvm/test/tools/llvm-readobj/COFF/unwind-arm64-windows.test
mlir/test/Dialect/Affine/loop-coalescing.mlir
mlir/test/Dialect/Linalg/fuse-with-reshape-by-collapsing.mlir
mlir/test/Dialect/Linalg/tile-and-fuse-no-fuse.mlir
mlir/test/Dialect/MemRef/canonicalize.mlir
mlir/test/Dialect/SPIRV/IR/memory-ops.mlir
mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir
mlir/test/IR/dynamic.mlir
mlir/test/mlir-tblgen/op-decl-and-defs.td
polly/test/ScopDetect/dot-scops-npm.ll

Removed: 




diff  --git a/clang/test/CodeGenCXX/attr-mustprogress.cpp 
b/clang/test/CodeGenCXX/attr-mustprogress.cpp
index 592ebd537cc73..4dac0a4b93b0d 100644
--- a/clang/test/CodeGenCXX/attr-mustprogress.cpp
+++ b/clang/test/CodeGenCXX/attr-mustprogress.cpp
@@ -125,7 +125,7 @@ void F() {
 // CHECK-NEXT:[[CMP:%.*]] = icmp eq i32 [[TMP0]], [[TMP1]]
 // CHECK-NEXT:br i1 [[CMP]], label %for.body, label %for.end
 // CHECK:   for.body:
-// CXX98_NOT: br {{.*}} !llvm.loop
+// CXX98-NOT: br {{.*}} !llvm.loop
 // CXX11-NEXT:br label %for.cond, !llvm.loop [[LOOP6:!.*]]
 // FINITE-NEXT:   br label %for.cond, !llvm.loop [[LOOP6:!.*]]
 // CHECK:   for.end:

diff  --git a/clang/test/CodeGenCXX/eh-aggregate-copy-destroy.cpp 
b/clang/test/CodeGenCXX/eh-aggregate-copy-destroy.cpp
index 9f0f36c875618..37d5b8654eee0 100644
--- a/clang/test/CodeGenCXX/eh-aggregate-copy-destroy.cpp
+++ b/clang/test/CodeGenCXX/eh-aggregate-copy-destroy.cpp
@@ -23,7 +23,7 @@ struct Container {
 int main () {
   try {
 Container c1;
-// CHECK_LABEL: main
+// CHECK-LABEL: main
 // CHECK-NOT: call void @_ZN9ThrowCopyC1ERKS_
 // CHECK: invoke void @_ZN9ThrowCopyC1ERKS_
 // CHECK98: invoke void @_ZN12ImplicitCopyD1Ev

diff  --git a/clang/test/CodeGenCXX/inheriting-constructor.cpp 
b/clang/test/CodeGenCXX/inheriting-constructor.cpp
index dffd13d9bfbcd..751604fad194c 100644
--- a/clang/test/CodeGenCXX/inheriting-constructor.cpp
+++ b/clang/test/CodeGenCXX/inheriting-constructor.cpp
@@ -93,7 +93,7 @@ namespace noninline_virt {
   C c(1, 2, &c);
   // Complete object ctor forwards to A ctor, then calls B's base inheriting
   // constructor, which takes no arguments other than the this pointer and VTT.
-  // ITANIUM_LABEL: define linkonce_odr void 
@_ZN14noninline_virt1CCI1NS_1AEEiO1QPvU

[clang] [clang-tools-extra] [flang] Fix OOM in FormatDiagnostic (2nd attempt) (PR #108866)

2024-10-18 Thread Ivan Kosarev via cfe-commits

kosarev wrote:

@igelbox This seems to cause `Clang-Unit :: Rename/./ClangRenameTests/*` 
failures on my machine. Still reproduces on the current top of branch, 
dbe47c2a06e0928edde802d062ecf1a0ce45fbb9. Anyone else can see the failures?

The `Clang-Unit :: AST/Interp/./InterpTests/*` failures are from before.

```
$ ninja check-clang-unit
...
Failed Tests (38):
  Clang-Unit :: AST/Interp/./InterpTests/1/5
  Clang-Unit :: AST/Interp/./InterpTests/2/5
  Clang-Unit :: AST/Interp/./InterpTests/3/5
  Clang-Unit :: AST/Interp/./InterpTests/4/5
  Clang-Unit :: AST/Interp/./InterpTests/Descriptor/Primitives
  Clang-Unit :: Rename/./ClangRenameTests/0/33
  Clang-Unit :: Rename/./ClangRenameTests/1/33
  Clang-Unit :: Rename/./ClangRenameTests/10/33
  Clang-Unit :: Rename/./ClangRenameTests/11/33
  Clang-Unit :: Rename/./ClangRenameTests/12/33
  Clang-Unit :: Rename/./ClangRenameTests/13/33
  Clang-Unit :: Rename/./ClangRenameTests/14/33
  Clang-Unit :: Rename/./ClangRenameTests/15/33
  Clang-Unit :: Rename/./ClangRenameTests/16/33
  Clang-Unit :: Rename/./ClangRenameTests/17/33
  Clang-Unit :: Rename/./ClangRenameTests/18/33
  Clang-Unit :: Rename/./ClangRenameTests/19/33
  Clang-Unit :: Rename/./ClangRenameTests/2/33
  Clang-Unit :: Rename/./ClangRenameTests/20/33
  Clang-Unit :: Rename/./ClangRenameTests/21/33
  Clang-Unit :: Rename/./ClangRenameTests/22/33
  Clang-Unit :: Rename/./ClangRenameTests/23/33
  Clang-Unit :: Rename/./ClangRenameTests/24/33
  Clang-Unit :: Rename/./ClangRenameTests/25/33
  Clang-Unit :: Rename/./ClangRenameTests/26/33
  Clang-Unit :: Rename/./ClangRenameTests/27/33
  Clang-Unit :: Rename/./ClangRenameTests/28/33
  Clang-Unit :: Rename/./ClangRenameTests/29/33
  Clang-Unit :: Rename/./ClangRenameTests/3/33
  Clang-Unit :: Rename/./ClangRenameTests/30/33
  Clang-Unit :: Rename/./ClangRenameTests/31/33
  Clang-Unit :: Rename/./ClangRenameTests/32/33
  Clang-Unit :: Rename/./ClangRenameTests/4/33
  Clang-Unit :: Rename/./ClangRenameTests/5/33
  Clang-Unit :: Rename/./ClangRenameTests/6/33
  Clang-Unit :: Rename/./ClangRenameTests/7/33
  Clang-Unit :: Rename/./ClangRenameTests/8/33
  Clang-Unit :: Rename/./ClangRenameTests/9/33


Testing Time: 5.04s

Total Discovered Tests: 18068
  Skipped: 4 (0.02%)
  Passed : 18026 (99.77%)
  Failed :38 (0.21%)
```

```
cmake \
  -DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
  -DCMAKE_C_COMPILER=clang \
  -DCMAKE_CXX_COMPILER=clang++ \
  -DLLVM_ENABLE_WERROR=OFF \
  -DLLVM_USE_LINKER=gold \
  -DBUILD_SHARED_LIBS=ON \
  -DCMAKE_BUILD_TYPE=RELEASE \
  -DCMAKE_INSTALL_PREFIX=.. \
  -DLLVM_ENABLE_ASSERTIONS=ON \
  -DLLVM_ENABLE_PROJECTS=clang \
  -GNinja \
```

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


[clang] [llvm] AMDGPU: Add gfx950 subtarget definitions (PR #116307)

2024-11-15 Thread Ivan Kosarev via cfe-commits


@@ -650,15 +650,15 @@ class VOP_SDWA_Pseudo  pattern=[]> :
   let Uses = !if(ReadsModeReg, [MODE, EXEC], [EXEC]);
 
   let SubtargetPredicate = HasSDWA;
-  let AssemblerPredicate = HasSDWA;
+  //let AssemblerPredicate = HasSDWA;

kosarev wrote:

Just remove the line?

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


[clang] [llvm] [AMDGPU][True16][MC] true16 for v_alignbyte_b32 (PR #119750)

2025-01-07 Thread Ivan Kosarev via cfe-commits


@@ -2353,8 +2353,8 @@ def int_amdgcn_writelane :
   [IntrNoMem, IntrConvergent, IntrWillReturn, IntrNoCallback, IntrNoFree]
 >;
 
-def int_amdgcn_alignbyte : ClangBuiltin<"__builtin_amdgcn_alignbyte">,
-  DefaultAttrsIntrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty, llvm_i32_ty],
+def int_amdgcn_alignbyte : DefaultAttrsIntrinsic<[llvm_i32_ty],
+  [llvm_i32_ty, llvm_i32_ty, llvm_anyint_ty],

kosarev wrote:

> pattern match extract of high bits. We generally shouldn't expose the direct 
> op_sel reads

That's what I meant by masking subtarget specifics. Nevermind then.

(Though I do still have doubts as to whether having pattern matching on top of 
such as a no-side-effects intrinsic is a good idea, because normally the 
intention behind using intrinsics would be not to rely on pattern matching and 
get it translated with guarantee to something of a very particular form. 
Otherwise, we could just pattern-match an equivalent tree that doesn't use any 
intrinsics at all.)

@broxigarchen Guo, so can we leave the intrinsic as is and on codegen just use 
the low half of src2 on GFX11+?

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


[clang] [llvm] [AMDGPU][True16][MC] true16 for v_alignbyte_b32 (PR #119750)

2025-01-07 Thread Ivan Kosarev via cfe-commits


@@ -2353,8 +2353,8 @@ def int_amdgcn_writelane :
   [IntrNoMem, IntrConvergent, IntrWillReturn, IntrNoCallback, IntrNoFree]
 >;
 
-def int_amdgcn_alignbyte : ClangBuiltin<"__builtin_amdgcn_alignbyte">,
-  DefaultAttrsIntrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty, llvm_i32_ty],
+def int_amdgcn_alignbyte : DefaultAttrsIntrinsic<[llvm_i32_ty],
+  [llvm_i32_ty, llvm_i32_ty, llvm_anyint_ty],

kosarev wrote:

The intrinsic currently doesn't support using the high half of src2 on 
pre-GFX11. If it ever will have to (I don't know that), then it seems there 
should be two separate intrinsics for pre-GFX11 and GFX11+.

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


[clang] [llvm] [AMDGPU][True16][MC][CodeGen] true16 for v_alignbyte_b32 (PR #119750)

2025-02-04 Thread Ivan Kosarev via cfe-commits

https://github.com/kosarev approved this pull request.

LGTM.

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


[clang] [llvm] [AMDGPU][True16][MC][CodeGen] true16 for v_alignbyte_b32 (PR #119750)

2025-02-04 Thread Ivan Kosarev via cfe-commits


@@ -1690,7 +1715,7 @@ defm V_FMA_F32 : 
VOP3_Realtriple_gfx11_gfx12<0x213>;
 defm V_FMA_F64 : VOP3_Real_Base_gfx11_gfx12<0x214>;
 defm V_LERP_U8 : VOP3_Realtriple_gfx11_gfx12<0x215>;
 defm V_ALIGNBIT_B32: VOP3_Realtriple_gfx11_gfx12<0x216>;
-defm V_ALIGNBYTE_B32   : VOP3_Realtriple_gfx11_gfx12<0x217>;
+defm V_ALIGNBYTE_B32   : VOP3_Realtriple_t16_and_fake16_gfx11_gfx12<0x217, 
"v_alignbyte_b32">;

kosarev wrote:

Nit: you can do `string asmName = !tolower(NAME)` in the multiclass.

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


[clang] [llvm] [AMDGPU][True16][MC][CodeGen] true16 for v_alignbyte_b32 (PR #119750)

2025-02-04 Thread Ivan Kosarev via cfe-commits

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


[clang] [llvm] [AMDGPU][True16][MC][CodeGen] true16 for v_alignbyte_b32 (PR #125706)

2025-02-06 Thread Ivan Kosarev via cfe-commits

kosarev wrote:

Same suggestion as in 
https://github.com/llvm/llvm-project/pull/119750#discussion_r1941297212.

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


[clang] [llvm] [AMDGPU][True16][MC] true16 for v_alignbyte_b32 (PR #119750)

2025-01-03 Thread Ivan Kosarev via cfe-commits


@@ -2353,8 +2353,8 @@ def int_amdgcn_writelane :
   [IntrNoMem, IntrConvergent, IntrWillReturn, IntrNoCallback, IntrNoFree]
 >;
 
-def int_amdgcn_alignbyte : ClangBuiltin<"__builtin_amdgcn_alignbyte">,
-  DefaultAttrsIntrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty, llvm_i32_ty],
+def int_amdgcn_alignbyte : DefaultAttrsIntrinsic<[llvm_i32_ty],
+  [llvm_i32_ty, llvm_i32_ty, llvm_anyint_ty],

kosarev wrote:

It's tricky this one. I see the operand is 16-bit on, e.g., GFX10 as well, and 
SP3 doesn't mind assembling, say, `v_alignbyte_b32 v5, vcc_hi, lit(0xaf123456), 
sel_hi(v255)`, but then that's packed math, and not true16. So it feels like 
for GFX10 it would probably be most natural for the instrinsic to take a 32-bit 
operand and maybe at some point even support an op_sel_hi kind of flag whereas 
on GFX11 that would/should be just a 16-bit value, and so it's not just about 
the type of the operand.

Maybe we should either keep it taking llvm_i32_ty and do the 
conversion/truncation where needed, thus letting the intrinsic to mask the 
subtarget specifics or alternatively have two separate instrinsics that reflect 
these specifics properly?

Just switching llvm_anyint_ty feels a bit like masking the actual issue.

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


[clang] [llvm] [AMDGPU][True16][MC] true16 for v_alignbyte_b32 (PR #119750)

2025-01-03 Thread Ivan Kosarev via cfe-commits

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


[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

2025-05-21 Thread Ivan Kosarev via cfe-commits


@@ -28,25 +30,39 @@ int bar(C *c) {
 
 int bar2(C *c) {
 // CHECK-NEW-LABEL: _Z4bar2P1C
-// CHECK-NEW: load i32, {{.*}}, !tbaa [[TAG_int:!.*]]
+// CHECK-NEW: load i32, {{.*}}, !tbaa [[TAG_C_x:!.*]]
   return c->x[2];
 }
 
 int bar3(C *c, int j) {
 // CHECK-NEW-LABEL: _Z4bar3P1Ci
-// CHECK-NEW: load i32, {{.*}}, !tbaa [[TAG_int:!.*]]
+// CHECK-NEW: load i32, {{.*}}, !tbaa [[TAG_C_x]]
   return c->x[j];

kosarev wrote:

Makes sense, thanks.

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


[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

2025-05-21 Thread Ivan Kosarev via cfe-commits

https://github.com/kosarev approved this pull request.

LGTM.

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


[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

2025-05-21 Thread Ivan Kosarev via cfe-commits


@@ -28,25 +30,39 @@ int bar(C *c) {
 
 int bar2(C *c) {
 // CHECK-NEW-LABEL: _Z4bar2P1C
-// CHECK-NEW: load i32, {{.*}}, !tbaa [[TAG_int:!.*]]
+// CHECK-NEW: load i32, {{.*}}, !tbaa [[TAG_C_x:!.*]]
   return c->x[2];
 }
 
 int bar3(C *c, int j) {
 // CHECK-NEW-LABEL: _Z4bar3P1Ci
-// CHECK-NEW: load i32, {{.*}}, !tbaa [[TAG_int:!.*]]
+// CHECK-NEW: load i32, {{.*}}, !tbaa [[TAG_C_x]]
   return c->x[j];

kosarev wrote:

Am I reading this right that the tag now says we access a 4-byte int in C at 
offset 4?

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