public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Carl Love <cel@us.ibm.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: dje.gcc@gmail.com, gcc-patches@gcc.gnu.org,
	Will Schmidt <will_schmidt@vnet.ibm.com>,
	Bill Schmidt <wschmidt@linux.vnet.ibm.com>,
	cel@ibm.com
Subject: RE: [Patch 3/5] rs6000, Add TI to TD (128-bit DFP) and TD to TI support
Date: Wed, 26 Aug 2020 11:23:45 -0700	[thread overview]
Message-ID: <4ca68e83eac3304d0a26024845e317dd5567f745.camel@us.ibm.com> (raw)
In-Reply-To: <20200820012907.GA28786@gate.crashing.org>

Segher:

On Wed, 2020-08-19 at 20:29 -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Tue, Aug 11, 2020 at 12:22:59PM -0700, Carl Love wrote:
> > +(define_insn "floattitd2"
> > +  [(set (match_operand:TD 0 "gpc_reg_operand" "=d")
> > +	(float:TD (match_operand:TI 1 "gpc_reg_operand" "v")))]
> > +  "TARGET_TI_VECTOR_OPS"
> > +  "dcffixqq %0,%1"
> > +  [(set_attr "type" "dfp")])
> 
> I wonder if this should just be TARGET_POWER10 now?  That goes for
> the
> whole series of course.
> 
<snip>
> 
> Looks fine otherwise.  Okay for trunk, modulo whatever we do with
> YARGET_TI_VECTOR_OPS.  Thanks!
> 
> 
> Segher

You commented on the TARGET_TI_VECTOR_OPS in patch 2 as well, i.e.

   > > +  /* The -mti-vector-ops option requires ISA 3.1 support and -maltivec for
   > > +     the 128-bit instructions.  Currently, TARGET_POWER10 is sufficient to
   > > +     enable it by default.  */
   > > +  if (TARGET_POWER10)
   > > +    {
   > > +      if (rs6000_isa_flags_explicit & OPTION_MASK_VSX)
   > > +   warning(0, ("%<-mno-altivec%> disables -mti-vector-ops (128-bit integer vector register operations)."));
   > > +      else
   > > +   rs6000_isa_flags |= OPTION_MASK_TI_VECTOR_OPS;
   > > +    }
   > 
   > It seems odd here that -maltivec is explicitly called out here.  That
   > should be default on for quite a while at this point.

   And the actual check it for -mvsx anyway?  Not sure I follow what this
   does at all.

So this all goes way back, the following is from a discussion way back
in November.   We added it thinking it would be good to be able to
enable/disable the 128-bit vector support, as I recall.  I have to
admit that I am struggling a bit to remember all the details as we
discussed them back then. 

The following is from an old email.


   Hi Carl,

   On Mon, Nov 18, 2019 at 12:18:48PM -0800, Carl Love wrote:
   > Per your other note, I change the test suite check, with spelling fix,
   > to:
   >  
   > # Return 1 if the can generate the 128-bit integer operations in ISA 3.1.
   > # That means the following 128-bit instructions can be generated:
   > # vadduqm, vsubuqm, vmsumcud, vdivsq, vdivuq, vmodsq, vmoduq, vcmpuq, vcmpsq,
   > # vrlq, vslq, vsrq.  The -mti-vector-ops flag enables the needed support.
   > # The -mti-vector-ops is enabled by default for -mcpu=future.  Sufficient
   > # to test if the vadduqm instruction is generated for ISA 3.1 support.
   > proc check_effective_target_ppc_native_128bit { } {                             
   >     return [check_no_messages_and_pattern_nocache \
   >                 ppc_native_128bit {\mvadduqm\M} assembly {
   >                     __int128_t test_add (__int128_t a, __int128_t b)
   >                     { return a + b; }           
   >                 } {-mti-vector-ops} ]
   > }

   Ah, very good, this will work fine :-)

   But without that -mti-vector-ops option?

   > > (We also need to test what happens with -mno-altivec, etc. --
   > > shouldn't
   > > be hard, should just do the same thing as it does on older CPUs).
   > 
   > So I tried compiling the test case with -mn-altivec and -mcpu=future
   > and I get a GCC crash.  :-(

   Think of it this way: it is good if developers get ICEs.  That way, users
   get fewer.  :-)

   > I updated the setting for rs6000_isa_flags in rs6000.c to:
   > 
   >   /* The -mti-vector-ops option requires ISA 3.1 support and -maltivec for
   >      the 128-bit instructions.  Currently, TARGET_FUTURE is sufficient to
   >      enable it by default.  */                                 
   >   if (TARGET_FUTURE)                                                            
   >     {                                                                           
   >       if (rs6000_isa_flags_explicit & OPTION_MASK_VSX)
   >         warning(0, ("%<-mno-altivec%> disables -mti-vector-ops (128-bit integer vector register operations)."));                            
   >       else                                                                      
   >         rs6000_isa_flags |= OPTION_MASK_TI_VECTOR_OPS;                          
   >     }
   >  
   > Now, I get:
   >  
   > $GCC_INSTALL/bin/gcc -g -mcpu=future -mno-altivec  int_128bit-runnable.c -o int_128bit-runnable
   > cc1: warning: ‘-mno-altivec’ disables vsx
   > cc1: warning: ‘-mno-altivec’ disables -mti-vector-ops (128-bit integer vector register operations).
   > 
   > without -mno-altivec it compiles with no warning or errors.  The object
   > dump has the expected vadduqm and vsubuqm instructions.

   That will do the trick.  Maybe you want the message to be quiet, (or
   quieter anyway), if you get testsuite fallout?  You will find out.

   > > > +mti-vector-ops
   > > > +Target Report Mask(TI_VECTOR_OPS) Var(rs6000_isa_flags)
   > > > +Use integer 128-bit instructions for a future architecture.
   > > 
   > > For upstream we should make this an internal option (so
   > > Undocumented), but
   > > it may be handy to keep the option more visible for now, sure.
   > 
   > I was kinda thinking it would probably be made internal down the road.
   > 
   > So with these changes, I think we have a good base patch to build on. 

   Yes!  Thank you, this looks like it will be much less problematic than I
   feared for :-)


   Segher

So, do we want to drop the option OPTION_MASK_TI_VECTOR_OPS at this
point and go with just TARGET_POWER10?  
 

                        Carl 


  reply	other threads:[~2020-08-26 18:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-11 19:01 [Patch 0/5] rs6000, 128-bit Binary Integer Operations Carl Love
2020-08-11 19:22 ` [Patch 1/5] rs6000, Add 128-bit sign extension support Carl Love
2020-08-13 17:36   ` Segher Boessenkool
2020-08-13 18:09     ` Carl Love
2020-08-13 18:29       ` Segher Boessenkool
2020-08-13 22:11         ` [EXTERNAL] " will schmidt
2020-08-13 22:55           ` Segher Boessenkool
2020-08-13 23:53             ` [EXTERNAL] " will schmidt
2020-08-18 21:50               ` Segher Boessenkool
2020-08-11 19:22 ` [Patch 2/5] rs6000, 128-bit multiply, divide, modulo, shift, compare Carl Love
2020-08-13 23:46   ` will schmidt
2020-08-20  1:06     ` Segher Boessenkool
2020-08-11 19:22 ` [Patch 3/5] rs6000, Add TI to TD (128-bit DFP) and TD to TI support Carl Love
2020-08-14 17:13   ` will schmidt
2020-08-20  1:29   ` Segher Boessenkool
2020-08-26 18:23     ` Carl Love [this message]
2020-09-10 17:36       ` Segher Boessenkool
2020-08-11 19:23 ` [Patch 4/5] rs6000, Test 128-bit shifts for just the int128 type Carl Love
2020-08-14 17:35   ` will schmidt
2020-08-20 21:50   ` Segher Boessenkool
2020-08-26 20:27     ` Carl Love
2020-09-10 17:52       ` Segher Boessenkool
2020-08-11 19:23 ` [Patch 5/5] rs6000, Conversions between 128-bit integer and floating point values Carl Love
2020-08-14 18:50   ` will schmidt
2020-08-20 22:36   ` Segher Boessenkool
2020-09-19  0:25   ` will schmidt

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=4ca68e83eac3304d0a26024845e317dd5567f745.camel@us.ibm.com \
    --to=cel@us.ibm.com \
    --cc=cel@ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=segher@kernel.crashing.org \
    --cc=will_schmidt@vnet.ibm.com \
    --cc=wschmidt@linux.vnet.ibm.com \
    /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).