* [PATCH] [amdgcn] Add support for unordered floating-point comparisons
@ 2020-04-02 14:55 Kwok Cheung Yeung
2020-04-02 15:36 ` Andrew Stubbs
0 siblings, 1 reply; 2+ messages in thread
From: Kwok Cheung Yeung @ 2020-04-02 14:55 UTC (permalink / raw)
To: GCC Patches, Andrew Stubbs
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
Hello
This patch adds support for the unordered floating-point comparison operators
(UNEQ, UNGE, UNGT, UNLE, UNLT), which return true if one of the operands is a
NaN. These comparisons can be generated by builtins such as __builtin_isgreater.
GCC 10 appears to have a fall-back if the unordered comparisons are not
available (by generating an unordered comparison first, followed by the main
comparison), whereas previous versions would simply throw an ICE. Still, it
should be a little more efficient to have direct support for these operators.
Tested on a GCN3 board with no regressions noted. Okay for trunk?
Kwok
[-- Attachment #2: unordered_fp.patch --]
[-- Type: text/plain, Size: 1545 bytes --]
commit ea811ce38ae2127554f0aca9cd34aca6e42f814d
Author: Kwok Cheung Yeung <kcy@codesourcery.com>
Date: Thu Apr 2 07:47:28 2020 -0700
amdgcn: Support unordered floating-point comparison operators
2020-04-02 Kwok Cheung Yeung <kcy@codesourcery.com>
gcc/
* config/gcn/gcn.c (print_operand): Handle unordered comparison
operators.
* config/gcn/predicates.md (gcn_fp_compare_operator): Add unordered
comparison operators.
diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index 12438cf..38b5b98 100644
--- a/gcc/config/gcn/gcn.c
+++ b/gcc/config/gcn/gcn.c
@@ -6007,6 +6007,21 @@ print_operand (FILE *file, rtx x, int code)
case UNORDERED:
s = "_u_";
break;
+ case UNEQ:
+ s = "_nlg_";
+ break;
+ case UNGE:
+ s = "_nlt_";
+ break;
+ case UNGT:
+ s = "_nle_";
+ break;
+ case UNLE:
+ s = "_ngt_";
+ break;
+ case UNLT:
+ s = "_nge_";
+ break;
case LTGT:
s = "_lg_";
break;
diff --git a/gcc/config/gcn/predicates.md b/gcc/config/gcn/predicates.md
index 7bf763a..91e5ca1 100644
--- a/gcc/config/gcn/predicates.md
+++ b/gcc/config/gcn/predicates.md
@@ -165,7 +165,7 @@
(match_code "eq,ne,gt,ge,lt,le,gtu,geu,ltu,leu"))
(define_predicate "gcn_fp_compare_operator"
- (match_code "eq,ne,gt,ge,lt,le,gtu,geu,ltu,leu,ordered,unordered,ltgt"))
+ (match_code "eq,ne,gt,ge,lt,le,gtu,geu,ltu,leu,ordered,unordered,uneq,unge,ungt,unle,unlt,ltgt"))
(define_predicate "unary_operator"
(match_code "not,popcount"))
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] [amdgcn] Add support for unordered floating-point comparisons
2020-04-02 14:55 [PATCH] [amdgcn] Add support for unordered floating-point comparisons Kwok Cheung Yeung
@ 2020-04-02 15:36 ` Andrew Stubbs
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Stubbs @ 2020-04-02 15:36 UTC (permalink / raw)
To: Kwok Cheung Yeung, GCC Patches
On 02/04/2020 15:55, Kwok Cheung Yeung wrote:
> Hello
>
> This patch adds support for the unordered floating-point comparison
> operators (UNEQ, UNGE, UNGT, UNLE, UNLT), which return true if one of
> the operands is a NaN. These comparisons can be generated by builtins
> such as __builtin_isgreater.
>
> GCC 10 appears to have a fall-back if the unordered comparisons are not
> available (by generating an unordered comparison first, followed by the
> main comparison), whereas previous versions would simply throw an ICE.
> Still, it should be a little more efficient to have direct support for
> these operators.
>
> Tested on a GCN3 board with no regressions noted. Okay for trunk?
OK, thanks.
Andrew
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-04-02 15:36 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-02 14:55 [PATCH] [amdgcn] Add support for unordered floating-point comparisons Kwok Cheung Yeung
2020-04-02 15:36 ` Andrew Stubbs
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).