From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-485465-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2259 invoked by alias); 11 Sep 2018 18:20:30 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 2242 invoked by uid 89); 11 Sep 2018 18:20:29 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=HTo:D*vnet.ibm.com
X-HELO: gate.crashing.org
Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Sep 2018 18:20:27 +0000
Received: from gate.crashing.org (localhost.localdomain [127.0.0.1])	by gate.crashing.org (8.14.1/8.14.1) with ESMTP id w8BIKOrb032747;	Tue, 11 Sep 2018 13:20:24 -0500
Received: (from segher@localhost)	by gate.crashing.org (8.14.1/8.14.1/Submit) id w8BIKMPb032730;	Tue, 11 Sep 2018 13:20:22 -0500
Date: Tue, 11 Sep 2018 18:20:00 -0000
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Will Schmidt <will_schmidt@vnet.ibm.com>
Cc: Bill Schmidt <wschmidt@linux.vnet.ibm.com>,        David Edelsohn <dje.gcc@gmail.com>,        GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, rs6000] fix PR86952 (p8-vec-xl-*.c tests)
Message-ID: <20180911182022.GH23155@gate.crashing.org>
References: <1536355654.5318.14.camel@brimstone.rchland.ibm.com> <20180907215419.GE23155@gate.crashing.org> <1536678285.5440.11.camel@brimstone.rchland.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1536678285.5440.11.camel@brimstone.rchland.ibm.com>
User-Agent: Mutt/1.4.2.3i
X-IsSubscribed: yes
X-SW-Source: 2018-09/txt/msg00568.txt.bz2

Hi again,

On Tue, Sep 11, 2018 at 10:04:45AM -0500, Will Schmidt wrote:
> On Fri, 2018-09-07 at 16:54 -0500, Segher Boessenkool wrote: 
> > On Fri, Sep 07, 2018 at 04:27:34PM -0500, Will Schmidt wrote:
> > > -/* { dg-final { scan-assembler-times "lvx" 4 } } */
> > > -/* { dg-final { scan-assembler-times "stvx"  4 } } */
> > > -/* { dg-final { scan-assembler-times "xxpermdi" 0 } } */
> > > +/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M} 4 } } */
> > > +/* { dg-final { scan-assembler-times {\mstvx\M|\mstxvd2x\M}  4 } } */
> > 
> > So you get xxpermdi when {l,st}xvd2x is generated?  What platform is that
> > on?  Is that the correct code to generate, or is this a regression?  Is
> > this the difference between LE and BE code generation?  So many questions,
> > I am sorry :-)
> 
> Hi, 
> No prob, thanks for the question.  :-) 
> 
> The -v2 test is new-ish, I added it when the gimple-folding for the
> vec_xst,vec_xl intrinsics went in since i was seeing some codegen
> variations at the time.  The check for the lvx,stvx instructions is
> valid IF the test is built for a power9 target.  The test actually
> specifies -mcpu=power8 in it's options, so it needs to handle the lxvd2x
> +xxpermdi and xxpermdi+stxvd2 instruction pairs as appropriate for that
> processor.

lvx is the old AltiVec instruction, that uses  (A+B)&-16  as address
for  lvx D,A,B .  The instruction new on power9 is lxv, which does
reg+imm (instead of reg+reg) addressing.

Maybe the expected result should be separated between BE and LE, or
similar.


Segher