From: Tejas Joshi <tejasjoshi9673@gmail.com>
To: gcc@gcc.gnu.org
Cc: Martin Jambor <mjambor@suse.cz>, hubicka@ucw.cz, joseph@codesourcery.com
Subject: Re: Expanding roundeven (Was: Re: About GSOC.)
Date: Fri, 14 Jun 2019 12:49:00 -0000 [thread overview]
Message-ID: <CACMrGjCdRDb-b2CZLPWUOY0NVC79eedaPWN4DNJ8oMA4KoR1Lg@mail.gmail.com> (raw)
In-Reply-To: <ri64l4t4d43.fsf@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]
> Of course the instruction is not present there, that is the next step in
> your project :-)
Yes, of course, but what I meant was that instructions for existing
round/ceil functions and not roundeven. If inlining for these
functions is available, how can I inspect such instructions getting
inlined maybe in a *.s file?
Also, I am trying to find appropriate places to introduce changes for
roundeven to be inlined. Attached patch is what I have tried so far to
find the places.
ix86_expand_roundeven have dummy code for the sake of time.
In i386.md:
1. How should roundeven be defined at certain places where existing
floor is defined as:
(define_int_attr rounding_insn
[(UNSPEC_FRNDINT_FLOOR "floor")
2. Also, can roundeven be handled like round_floor is handled by:
(define_expand "<rounding_insn><mode>2"
but definitely with certain changes of flags, options and macros.
Thanks,
--Tejas
On Thu, 13 Jun 2019 at 22:49, Martin Jambor <mjambor@suse.cz> wrote:
>
> Hi Tejas,
>
> On Thu, Jun 13 2019, Tejas Joshi wrote:
> > Hello.
> > As further part of implementing roundeven is inlining, I was studying
> > machine descriptions and I have a few questions.
> >
> > As suggested, builtin functions provided a strong model for
> > implementing roundeven. Keeping that in mind, I tried to inspect how
> > similar functions (round/ceil) would get inlined. As it is dependent
> > on target machine, (mine is i7, so should be x86_64 ? I wonder why
> > gcc/config/ does not have x86_64 or amd64 directory. Or is it i386
> > itself as extended?),
>
> Yes, the directory with x86_64 specific stuff is i386.
>
> > should *.s file after compilation contain the
> > specific instruction if supported? I was unable to see such kind of
> > instruction on any -O level.
> >
>
> I am not sure I understand your question. Yes, the intent is that when
> the compiler cannot determine the argument of roundeven to be constant,
> it should emit the instruction instead of a library call, if the target
> architecture supports it. (and if IIUC, the intent is to use the 0 mode
> from table 4-8 in
> https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
> in instructions that take a rounding a mode to implement roundeven).
>
> Of course the instruction is not present there, that is the next step in
> your project :-)
>
> > Different pattern names are available for machine descriptions
> > <https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html>, also for
> > round, ceil, etc. Will I have to add such pattern name for roundeven?
> > (is it the same as optab defined in optabs.def?)
>
> Yes.
>
> Martin
[-- Attachment #2: roundeven-md.patch --]
[-- Type: text/x-patch, Size: 5033 bytes --]
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 85a945877a4..291717da7ee 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2723,6 +2723,9 @@ expand_builtin_int_roundingfn (tree exp, rtx target)
fallback_fn = BUILT_IN_FLOOR;
break;
+ CASE_FLT_FN (BUILT_IN_ROUNDEVEN):
+ builtin_optab = roundeven_optab;
+
default:
gcc_unreachable ();
}
@@ -7346,6 +7349,7 @@ expand_builtin (tree exp, rtx target, rtx subtarget, machine_mode mode,
return target;
break;
+ CASE_FLT_FN (BUILT_IN_ROUNDEVEN):
CASE_FLT_FN (BUILT_IN_ICEIL):
CASE_FLT_FN (BUILT_IN_LCEIL):
CASE_FLT_FN (BUILT_IN_LLCEIL):
diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index e547dda80f1..5cd255d24ef 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -902,6 +902,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_round
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundsd, "__builtin_ia32_roundsd", IX86_BUILTIN_ROUNDSD, UNKNOWN, (int) V2DF_FTYPE_V2DF_V2DF_INT)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundss, "__builtin_ia32_roundss", IX86_BUILTIN_ROUNDSS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF_INT)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundevenpd, "__builtin_ia32_roundevenpd", IX86_BUILTIN_ROUNDEVENPD, (enum rtx_code) ROUND_ROUNDEVEN, (int) V2DF_FTYPE_V2DF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_floorpd", IX86_BUILTIN_FLOORPD, (enum rtx_code) ROUND_FLOOR, (int) V2DF_FTYPE_V2DF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_ceilpd", IX86_BUILTIN_CEILPD, (enum rtx_code) ROUND_CEIL, (int) V2DF_FTYPE_V2DF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_truncpd", IX86_BUILTIN_TRUNCPD, (enum rtx_code) ROUND_TRUNC, (int) V2DF_FTYPE_V2DF_ROUND)
@@ -913,6 +914,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__buil
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_roundv2df2, "__builtin_ia32_roundpd_az", IX86_BUILTIN_ROUNDPD_AZ, UNKNOWN, (int) V2DF_FTYPE_V2DF)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_roundv2df2_vec_pack_sfix, "__builtin_ia32_roundpd_az_vec_pack_sfix", IX86_BUILTIN_ROUNDPD_AZ_VEC_PACK_SFIX, UNKNOWN, (int) V4SI_FTYPE_V2DF_V2DF)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_roundevenps", IX86_BUILTIN_ROUNDEVENPS, (enum rtx_code) ROUND_ROUNDEVEN, (int) V4SF_FTYPE_V4SF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_floorps", IX86_BUILTIN_FLOORPS, (enum rtx_code) ROUND_FLOOR, (int) V4SF_FTYPE_V4SF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_ceilps", IX86_BUILTIN_CEILPS, (enum rtx_code) ROUND_CEIL, (int) V4SF_FTYPE_V4SF_ROUND)
BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_truncps", IX86_BUILTIN_TRUNCPS, (enum rtx_code) ROUND_TRUNC, (int) V4SF_FTYPE_V4SF_ROUND)
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 0585c7d08bd..ad88c1a7e12 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -16094,6 +16094,16 @@ ix86_expand_rounddf_32 (rtx operand0, rtx operand1)
emit_move_insn (operand0, res);
}
+void
+ix86_expand_roundeven (rtx operand0, rtx operand1)
+{
+ machine_mode mode = GET_MODE (operand0);
+ rtx xa, xi, TWO52, res, mask;
+
+ res = gen_reg_rtx (mode);
+ emit_move_insn (res, operand1);
+}
+
/* Expand SSE sequence for computing trunc from OPERAND1 storing
into OPERAND0. */
void
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 01338e294ab..e81ba12161e 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -303,7 +303,8 @@
;; Constants to represent rounding modes in the ROUND instruction
(define_constants
- [(ROUND_FLOOR 0x1)
+ [(ROUND_ROUNDEVEN) 0x0)
+ (ROUND_FLOOR 0x1)
(ROUND_CEIL 0x2)
(ROUND_TRUNC 0x3)
(ROUND_MXCSR 0x4)
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index 016301a58d8..c07d48594e3 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -231,6 +231,7 @@ DEF_INTERNAL_FLT_FLOATN_FN (FLOOR, ECF_CONST, floor, unary)
DEF_INTERNAL_FLT_FLOATN_FN (NEARBYINT, ECF_CONST, nearbyint, unary)
DEF_INTERNAL_FLT_FLOATN_FN (RINT, ECF_CONST, rint, unary)
DEF_INTERNAL_FLT_FLOATN_FN (ROUND, ECF_CONST, round, unary)
+DEF_INTERNAL_FLT_FLOATN_FN (ROUNDEVEN, ECF_CONST, roundeven, unary)
DEF_INTERNAL_FLT_FLOATN_FN (TRUNC, ECF_CONST, btrunc, unary)
/* Binary math functions. */
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 8af3a2f43fd..839d250b8c6 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -267,6 +267,7 @@ OPTAB_D (fnms_optab, "fnms$a4")
OPTAB_D (rint_optab, "rint$a2")
OPTAB_D (round_optab, "round$a2")
+OPTAB_D (roundeven_optab, "roundeven$a2")
OPTAB_D (floor_optab, "floor$a2")
OPTAB_D (ceil_optab, "ceil$a2")
OPTAB_D (btrunc_optab, "btrunc$a2")
next prev parent reply other threads:[~2019-06-14 12:49 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACMrGjCeaZ7EoYqjLYiAJXjOtOfpJNo9zcbWhfarfkiLMN8YYA@mail.gmail.com>
2018-10-13 4:43 ` About GSOC Tejas Joshi
2018-10-23 10:47 ` Martin Jambor
2018-10-23 16:51 ` Joseph Myers
2018-11-16 16:50 ` Tejas Joshi
2018-11-16 19:00 ` Joseph Myers
2019-01-21 19:13 ` Tejas Joshi
2019-01-21 23:03 ` Joseph Myers
2019-01-23 2:55 ` Tejas Joshi
2019-01-23 4:00 ` Tejas Joshi
2019-01-23 17:37 ` Joseph Myers
2019-01-25 19:52 ` Tejas Joshi
2019-01-25 21:32 ` Joseph Myers
2019-01-28 17:00 ` Tejas Joshi
2019-02-04 14:39 ` Tejas Joshi
2019-02-04 15:06 ` Prathamesh Kulkarni
2019-02-04 15:56 ` Tejas Joshi
2019-02-04 16:44 ` Prathamesh Kulkarni
2019-02-04 17:22 ` Tejas Joshi
2019-02-24 12:05 ` Tejas Joshi
2019-03-30 11:24 ` Tejas Joshi
2019-04-01 19:53 ` Joseph Myers
2019-04-04 13:04 ` Tejas Joshi
2019-05-04 11:20 ` Tejas Joshi
2019-05-07 17:18 ` Joseph Myers
2019-05-07 19:38 ` Tejas Joshi
2019-05-07 21:01 ` Joseph Myers
2019-05-08 3:27 ` Tejas Joshi
2019-05-08 7:30 ` Tejas Joshi
2019-05-08 14:21 ` Tejas Joshi
2019-05-09 17:01 ` Joseph Myers
2019-05-09 16:55 ` Joseph Myers
2019-05-20 15:49 ` Martin Jambor
2019-05-20 21:48 ` Joseph Myers
2019-05-29 11:21 ` Tejas Joshi
2019-05-29 18:45 ` Tejas Joshi
2019-05-30 17:08 ` Martin Jambor
2019-05-30 21:38 ` Segher Boessenkool
2019-05-31 10:11 ` Martin Jambor
2019-05-31 10:28 ` Tejas Joshi
2019-06-03 16:38 ` Joseph Myers
2019-06-04 7:03 ` Tejas Joshi
2019-06-05 12:19 ` Tejas Joshi
2019-06-06 16:43 ` Joseph Myers
2019-06-09 4:48 ` Tejas Joshi
2019-06-10 20:26 ` Joseph Myers
2019-06-12 18:52 ` Tejas Joshi
2019-06-13 12:33 ` Tejas Joshi
2019-06-13 17:19 ` Expanding roundeven (Was: Re: About GSOC.) Martin Jambor
2019-06-13 21:16 ` Joseph Myers
2019-06-14 12:49 ` Tejas Joshi [this message]
2019-06-14 17:32 ` Martin Jambor
2019-06-17 7:50 ` Tejas Joshi
2019-06-17 17:15 ` Joseph Myers
2019-06-19 13:32 ` Tejas Joshi
2019-06-22 17:11 ` Tejas Joshi
2019-06-22 17:37 ` Jan Hubicka
2019-06-17 17:10 ` Joseph Myers
2019-05-31 11:13 ` About GSOC Segher Boessenkool
2019-05-31 11:16 ` Nathan Sidwell
2019-05-31 13:30 ` Eric Gallager
2019-06-03 9:37 ` Tejas Joshi
2019-06-06 16:56 ` Committing patches and other conventions (Was: Re: About GSOC) Martin Jambor
2019-06-09 4:57 ` Tejas Joshi
2019-06-12 13:48 ` Tejas Joshi
2019-06-13 17:02 ` Martin Jambor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACMrGjCdRDb-b2CZLPWUOY0NVC79eedaPWN4DNJ8oMA4KoR1Lg@mail.gmail.com \
--to=tejasjoshi9673@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=joseph@codesourcery.com \
--cc=mjambor@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).