Author: Joe Nash
Date: 2022-04-29T12:27:17-04:00
New Revision: 813e521e55b11165138b071f446eda94b14570dc
URL:
https://github.com/llvm/llvm-project/commit/813e521e55b11165138b071f446eda94b14570dc
DIFF:
https://github.com/llvm/llvm-project/commit/813e521e55b11165138b071f446eda94b14570dc.diff
LOG:
Author: Joe Nash
Date: 2022-04-29T13:55:56-04:00
New Revision: 8bdfc73f633dca9859123b8596bcb521700c6a7f
URL:
https://github.com/llvm/llvm-project/commit/8bdfc73f633dca9859123b8596bcb521700c6a7f
DIFF:
https://github.com/llvm/llvm-project/commit/8bdfc73f633dca9859123b8596bcb521700c6a7f.diff
LOG:
Mirko =?utf-8?q?Brkušanin?= ,
Mirko =?utf-8?q?Brkušanin?= ,Mirko Brkusanin
,Mariusz Sikora
Message-ID:
In-Reply-To:
https://github.com/Sisyph commented:
DPP changes look good, and functionally I'm fine with the patch.
I don't think the tablegen 'bit IsFP8' version of managing the op_sel bits
Mirko =?utf-8?q?Brkušanin?= ,
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
Mirko =?utf-8?q?Brkušanin?= ,
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
Author: Joe Nash
Date: 2022-06-16T14:19:34-04:00
New Revision: 2d43de13df03eab0fda1023b22b335b207afc507
URL:
https://github.com/llvm/llvm-project/commit/2d43de13df03eab0fda1023b22b335b207afc507
DIFF:
https://github.com/llvm/llvm-project/commit/2d43de13df03eab0fda1023b22b335b207afc507.diff
LOG:
Sisyph wrote:
> I've just tested this on 1 graphics shaders and it seems to make no
> difference at all. I tried gfx900 and gfx1100. Can anyone else from the
> graphics team confirm this?
I can confirm no difference on gfx1102
https://github.com/llvm/llvm-project/pull/67878
__
Sisyph wrote:
> I've just tested this on 1 graphics shaders and it seems to make no
> difference at all. I tried gfx900 and gfx1100. Can anyone else from the
> graphics team confirm this?
I can confirm no difference on gfx1102
https://github.com/llvm/llvm-project/pull/67878
__
https://github.com/Sisyph commented:
LGTM but please wait for the other reviewers.
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
https://github.com/Sisyph 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
@@ -1,10 +1,48 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
; RUN: llc -mtriple=amdgcn -verify-machineinstrs < %s | FileCheck
-check-prefix=GCN %s
+; RUN: llc -mtriple=amdgcn -mcpu=gfx1100 -mattr=+real-true16
-verify-m
@@ -3802,6 +3802,26 @@ def : FPMinCanonMaxPat, fmaximum_oneuse>;
}
+let True16Predicate = UseFakeTrue16Insts in
+def : GCNPat <
+(i32 (int_amdgcn_alignbyte (i32 (VOP3OpSelMods i32:$src0,
i32:$src0_modifiers)),
+ (i32 (VOP3OpSelMods i32:$src1,
i32:$sr
@@ -3802,6 +3802,26 @@ def : FPMinCanonMaxPat, fmaximum_oneuse>;
}
+let True16Predicate = UseFakeTrue16Insts in
+def : GCNPat <
+(i32 (int_amdgcn_alignbyte (i32 (VOP3OpSelMods i32:$src0,
i32:$src0_modifiers)),
Sisyph wrote:
Instead of this fake16 pattern, can
13 matches
Mail list logo