Re: [PATCH] Deprecate ia64*-*-*

[Richard Biener]

On Thu, 13 Jun 2019, Jim Wilson wrote:

> On Thu, Jun 13, 2019 at 10:39 AM Joel Sherrill  
> wrote:
> > Ok with me if no one steps up and the downstream projects like Debian gets
> > notice. This is just a reflection of this architecture's status in the
> > world.
> 
> I sent email to the debian-ia64 list half an hour ago.  Just got a
> response.  They mentioned that there is also a gentoo group that I
> didn't know about, and want to know why exactly we want to deprecate
> it.  I can discuss it with them.

The deprecation reason is a formal one - we do not have a listed
maintainer for the port which is a requirement for port acceptance
and IMHO should be a requirement for it to stay (not sure if that's
written anywhere).  Note GCC 10 will still have the ia64 port it
is just that GCC 11 may not in case nobody steps up as maintainer.

In some way it is also documenting to possible users that their
(target specific) bugs may receive no attention.

Richard.

Re: Expanding roundeven (Was: Re: About GSOC.)

[Tejas Joshi]

> 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 "2"
but definitely with certain changes of flags, options and macros.

Thanks,
--Tejas



On Thu, 13 Jun 2019 at 22:49, Martin Jambor  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
> > , 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
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, 

Re: [PATCH] Deprecate ia64*-*-*

[Jeff Law]

On 6/14/19 1:14 AM, Richard Biener wrote:
> On Thu, 13 Jun 2019, Jim Wilson wrote:
> 
>> On Thu, Jun 13, 2019 at 10:39 AM Joel Sherrill  
>> wrote:
>>> Ok with me if no one steps up and the downstream projects like Debian gets
>>> notice. This is just a reflection of this architecture's status in the
>>> world.
>>
>> I sent email to the debian-ia64 list half an hour ago.  Just got a
>> response.  They mentioned that there is also a gentoo group that I
>> didn't know about, and want to know why exactly we want to deprecate
>> it.  I can discuss it with them.
> 
> The deprecation reason is a formal one - we do not have a listed
> maintainer for the port which is a requirement for port acceptance
> and IMHO should be a requirement for it to stay (not sure if that's
> written anywhere).  Note GCC 10 will still have the ia64 port it
> is just that GCC 11 may not in case nobody steps up as maintainer.
> 
> In some way it is also documenting to possible users that their
> (target specific) bugs may receive no attention.
Right.  One could claim many other targets should be reviewed for
possible deprecation.

Jeff

Re: Expanding roundeven (Was: Re: About GSOC.)

[Martin Jambor]

Hi,

On Fri, Jun 14 2019, Tejas Joshi wrote:
>> 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?

Make sure you compile to a target that has the rounding instruction,
i.e. by using an appropriate -march or -mavx) and also specify
-ffast-math on the command line.  I have not double checked, but I
assume the latter is necessary (mainly) because it implies
-fno-math-errno and most of the math builtin expansion into instructions
is guarded by check for !flag_errno_math.

So e.g. my test input:

  double
  callplusone (double d)
  {
return __builtin_round (d) + 1;
  }

has vroundsd instruction in the output of:

  ~/gcc/trunk/inst/bin/gcc -O2 -S expand_example.c -mavx -ffast-math

>
> 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.

So far I only quickly glanced over it but it seems to be going in the
right direction.  I'll try to answer the rest of your questions as soon
as I can but I also have to look a bit into the machine descriptions
myself first.

Martin


> 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 "2"
> but definitely with certain changes of flags, options and macros.
>
> Thanks,
> --Tejas

Re: ARM peephole2 from 2003 never merged, still valid

[Jeff Law]

On 6/6/19 10:06 AM, Richard Earnshaw (lists) wrote:
> On 06/06/2019 15:55, Fredrik Hederstierna wrote:
>>> From: Segher Boessenkool 
>>> Sent: Thursday, June 6, 2019 4:02 PM
>>> To: Richard Earnshaw (lists)
>>> Cc: Jeff Law; Fredrik Hederstierna; gcc@gcc.gnu.org
>>> Subject: Re: ARM peephole2 from 2003 never merged, still valid
>>   
>>> That doesn't stop combine from considering it.  It does make that first SET
>>> survive, so that you get a parallel as final insn.  It may not like that
>>> one of the parallel SETs is just a move.  Needs testcase :-)
>>  
>> Hi all, thanks for investigating this,
>> I added semi-stripped testcase in original issue taken from CSiBE teem 
>> sources
>>
>> See attachment in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9663
>>
>> Tested gcc-9.1.0 for ARM 32bit targets, first without peephole2 patch:
>>
>>  :
>>0:e92d407fpush{r0, r1, r2, r3, r4, r5, r6, lr}
>>4:e2504000subsr4, r0, #0
>>8:0a3fbeq 10c 
>>c:e351cmp r1, #0
>>   10:e1a05001mov r5, r1
>>
>> then with new peephole2 patch:
>>
>>  :
>>0:e92d407fpush{r0, r1, r2, r3, r4, r5, r6, lr}
>>4:e2504000subsr4, r0, #0
>>8:0a3ebeq 108 
>>c:e2515000subsr5, r1, #0
>>
>> Thanks, Fredrik
>>
> 
> The reason combine doesn't catch this is because at the time it runs the
> MOV is in a different basic block.  Later on it is sunk into the same
> basic block, but it's then too late to do the merge.
And while this looks well suited for compare-elim, nobody's done the
work to enable compare-elim on ARM.  It may also be the case that
compare-elim is still too early, at least for the testcase in the PR.

So should we just go with the peephole2?
jeff

Re: [Combine] Unusual behaviour in combine

[Segher Boessenkool]

On Wed, Jun 12, 2019 at 10:52:42AM +, Joel Hutton wrote:
> A summary of the behaviour is:
> when combining A -> B, the register equivalence notes of A are checked, the 
> register notes of B are not checked.
> 
> Is this expected behaviour?

Yes.

If it would use the notes on B to make the new insns, it would not need A
*at all*.  This does not make much sense.

A worse problem is that very often it will end up with an insn that cannot
match, if it did use the note on i3.  combine does not try all ways it can
transform your code, so it should use the more promising ways.

> Combine does not check the REG_EQUAL note on insn 12, and does not try the 
> equivalent pattern, using a const_vector instead of register 99.
> 
> Trying 10 -> 12:
>    10: r97:V4SF=float(r96:V4SI)
>   REG_DEAD r96:V4SI
>    12: r98:V4SF=r97:V4SF*r99:V4SF
>   REG_DEAD r97:V4SF
>   REG_EQUAL r97:V4SF*const_vector
> Failed to match this instruction:
> (set (reg:V4SF 98 [ D.3422 ])
>     (mult:V4SF (float:V4SF (reg:V4SI 96 [ D.3420 ]))
>     (reg:V4SF 99)))

If you want the const_vector for r97, you should look at the combination
that tries *that* insn together with 10 and 12.  Did it try that?  Why not?


Segher

gcc-8-20190614 is now available

[gccadmin]

Snapshot gcc-8-20190614 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190614/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch 
revision 272314

You'll find:

 gcc-8-20190614.tar.xzComplete GCC

  SHA256=7626bfb25fc42ef636404b8a33b5a06eb367d569f06934efec29103394378f6d
  SHA1=48cc1b8a3d6092c4bf80d9bc06109005b1f75888

Diffs from 8-20190607 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [PATCH] Deprecate ia64*-*-*

[Jason Duerstock]

I volunteer to be maintainer for ia64.

Jason