On 5/6/23 06:53, jinma wrote:
diff --git a/gcc/config/riscv/iterators.md b/gcc/config/riscv/iterators.md
index 9b767038452..c81b08e3cc5 100644
--- a/gcc/config/riscv/iterators.md
+++ b/gcc/config/riscv/iterators.md
@@ -288,3 +288,8 @@ (define_int_iterator QUIET_COMPARISON [UNSPEC_FLT_QUIET
UNSPEC_FLE_QUIET])
(define_int_attr quiet_pattern [(UNSPEC_FLT_QUIET "lt") (UNSPEC_FLE_QUIET
"le")])
(define_int_attr QUIET_PATTERN [(UNSPEC_FLT_QUIET "LT") (UNSPEC_FLE_QUIET
"LE")])
+(define_int_iterator ROUND [UNSPEC_ROUND UNSPEC_FLOOR UNSPEC_CEIL UNSPEC_BTRUNC UNSPEC_ROUNDEVEN UNSPEC_NEARBYINT])
+(define_int_attr round_pattern [(UNSPEC_ROUND "round") (UNSPEC_FLOOR "floor")
(UNSPEC_CEIL "ceil")
+ (UNSPEC_BTRUNC "btrunc") (UNSPEC_ROUNDEVEN "roundeven")
(UNSPEC_NEARBYINT "nearbyint")])
+(define_int_attr round_rm [(UNSPEC_ROUND "rmm") (UNSPEC_FLOOR "rdn") (UNSPEC_CEIL
"rup")
+ (UNSPEC_BTRUNC "rtz") (UNSPEC_ROUNDEVEN "rne")
(UNSPEC_NEARBYINT "dyn")])
Do we really need to use unspecs for all these cases? I would expect
some correspond to the trunc, round, ceil, nearbyint, etc well known RTX
codes.
In general, we should try to avoid unspecs when there is a clear
semantic match between the instruction and GCC's RTX opcodes. So please
review the existing RTX code semantics to see if any match the new
instructions. If there are matches, use those RTX codes rather than
UNSPECs.
I'll try, thanks.
I encountered some confusion about this. I checked gcc's documents and
found no RTX codes that can correspond to round, ceil, nearbyint, etc.
Only "(fix:m x)" seems to correspond to trunc, which can be expressed
as rounding towards zero, while others have not yet been found.
You're largely correct. My bad. There's named patterns for round to
integer, nearbyint, etc, but no RTX codes. So they need to be handled
as unspecs. Sorry fo the confusion.
Jeff
