From: Segher Boessenkool <segher@kernel.crashing.org>
To: will schmidt <will_schmidt@vnet.ibm.com>
Cc: gcc-patches@gcc.gnu.org, David Edelsohn <dje.gcc@gmail.com>,
Peter Bergner <bergner@linux.ibm.com>
Subject: Re: rs6000: RFC/Update support for addg6s instruction. PR100693
Date: Wed, 16 Mar 2022 15:59:49 -0500 [thread overview]
Message-ID: <20220316205949.GL614@gate.crashing.org> (raw)
In-Reply-To: <670b4207d259cd325822d8bc0c1dac9a892ee765.camel@vnet.ibm.com>
On Wed, Mar 16, 2022 at 03:06:42PM -0500, will schmidt wrote:
> On Wed, 2022-03-16 at 13:12 -0500, Segher Boessenkool wrote:
> > (define_insn "addg6s"
> > [(set (match_operand:GPR 0 "register_operand" "=r")
> > (unspec:GPR [(match_operand:GPR 1 "register_operand" "r")
> > (match_operand:GPR 2 "register_operand" "r")]
> > UNSPEC_ADDG6S))]
> > "TARGET_POPCNTD"
> > "addg6s %0,%1,%2"
> > [(set_attr "type" "integer")])
> > You do not need multiple unspec numbers. You can differentiate
> them
> > based on the modes of the arguments, already :-)
>
> Yeah, Thats what I thought, which is a big part of why I posted this
> with RFC. :-) When I attempted this there was an issue with multiple
> <mode>s (behind the GPR predicate) versus the singular "addg6s"
> define_insn.
> It's possible I had something else wrong there, but I'll
> go back to that attempt and work in that direction.
No, that is still there. One way out is to make this an unnamed pattern
(like "*addg6s"). Another is to put the mode in the name, and then you
probably want to make it a parameterized name as well, which then hides
all that again:
(define_insn "@addg6s"
...
> > > +/* { dg-require-effective-target powerpc_vsx_ok } */
> >
> > That is the wrong requirement. You want to test for Power7, not for
> > VSX. I realise you probably copied this from elsewhere :-( (If from
> > another addg6s testcase, just keep it).
>
> Because reasons. :-) The stanzas are copied from the nearby bcd-1.c
> testcase that has a simpler test for addg6s. Given the input I'll
> try to correct the stanzas here and limit how much error I carry along.
If you do not improve the existing ones it may be best to just keep this
the same in the new testcases as well. Consistency is a good thing.
Consistent wrong is not so great of course :-)
Segher
prev parent reply other threads:[~2022-03-16 21:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-16 17:20 will schmidt
2022-03-16 18:12 ` Segher Boessenkool
2022-03-16 20:06 ` will schmidt
2022-03-16 20:59 ` Segher Boessenkool [this message]
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=20220316205949.GL614@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=bergner@linux.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=will_schmidt@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).