From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19807 invoked by alias); 16 May 2014 10:56:44 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 19798 invoked by uid 89); 16 May 2014 10:56:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pb0-f42.google.com Received: from mail-pb0-f42.google.com (HELO mail-pb0-f42.google.com) (209.85.160.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 16 May 2014 10:56:42 +0000 Received: by mail-pb0-f42.google.com with SMTP id md12so2484393pbc.1 for ; Fri, 16 May 2014 03:56:40 -0700 (PDT) X-Received: by 10.66.244.176 with SMTP id xh16mr19848785pac.20.1400237800674; Fri, 16 May 2014 03:56:40 -0700 (PDT) Received: from [192.168.1.35] (76-253-2-104.lightspeed.sntcca.sbcglobal.net. [76.253.2.104]) by mx.google.com with ESMTPSA id ha3sm13948661pbc.5.2014.05.16.03.56.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 03:56:39 -0700 (PDT) References: <006f01cf6b71$1cf10df0$56d329d0$@arm.com> <000001cf70ee$9aa2ed90$cfe8c8b0$@arm.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: Thomas Preud'homme , GCC Patches From: pinskia@gmail.com Subject: Re: [PATCH] Fix PR54733 Optimize endian independent load/store Date: Fri, 16 May 2014 10:56:00 -0000 To: Richard Biener X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg01263.txt.bz2 > On May 16, 2014, at 3:48 AM, Richard Biener = wrote: >=20 > On Fri, May 16, 2014 at 12:07 PM, Thomas Preud'homme > wrote: >> Ping? >=20 > Sorry ... >=20 >> Best regards, >>=20 >> Thomas Preud'homme >>=20 >>> -----Original Message----- >>> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches- >>> owner@gcc.gnu.org] On Behalf Of Thomas Preud'homme >>> Sent: Friday, May 09, 2014 6:26 PM >>> To: GCC Patches >>> Subject: RE: [PATCH] Fix PR54733 Optimize endian independent load/store >>>=20 >>> Sorry, took longer than expected as I got distracted by some other patc= h. >>> I merged the whole patchset in a single patch as I was told the current= setup >>> is actually more difficult to read. >>>=20 >>> Here are the updated ChangeLogs: >>>=20 >>> *** gcc/ChangeLog *** >>>=20 >>> 2014-05-09 Thomas Preud'homme >>>=20 >>> PR tree-optimization/54733 >>> * expr.c (get_inner_reference): Add a parameter to control whether >>> a >>> MEM_REF should be split into base + offset. >>> * tree.h (get_inner_reference): Default new parameter to false. >>> * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure. >>> (CMPNOP): Define. >>> (find_bswap_or_nop_load): New. >>> (find_bswap_1): Renamed to ... >>> (find_bswap_or_nop_1): This. Also add support for memory source. >>> (find_bswap): Renamed to ... >>> (find_bswap_or_nop): This. Also add support for memory source and >>> detection of bitwise operations equivalent to load in host endiann= ess. >>> (execute_optimize_bswap): Likewise. Also move its leading >>> comment back >>> in place and split statement transformation into ... >>> (bswap_replace): This. Add assert when updating bswap_stats. >>>=20 >>> *** gcc/testsuite/ChangeLog *** >>>=20 >>> 2014-05-09 Thomas Preud'homme >>>=20 >>> PR tree-optimization/54733 >>> * gcc.dg/optimize-bswapdi-3.c: New test to check extension of >>> bswap >>> optimization to support memory sources and bitwise operations >>> equivalent to load in host endianness. >>> * gcc.dg/optimize-bswaphi-1.c: Likewise. >>> * gcc.dg/optimize-bswapsi-2.c: Likewise. >>> * gcc.c-torture/execute/bswap-2.c: Likewise. >>>=20 >>> Ok for trunk? >=20 > Ok, I now decided otherwise and dislike the new parameter to > get_inner_reference. Can you please revert that part and just > deal with a MEM_REF result in your only caller? >=20 > And (of course) I found another possible issue. The way you > compute load_type and use it here: >=20 > + /* Perform the load. */ > + load_offset_ptr =3D build_int_cst (n->alias_set, 0); > + val_expr =3D fold_build2 (MEM_REF, load_type, addr_tmp, > + load_offset_ptr); >=20 > makes the load always appear aligned according to the mode of > load_type. On strict-alignment targets this may cause faults. >=20 > So what you have to do is either (simpler) >=20 > unsigned int align =3D get_pointer_alignment (addr_tmp); > tree al_load_type =3D load_type; > if (align < TYPE_ALIGN (load_type)) > al_load_type =3D build_aligned_type (load_type, align); > ... > val_expr =3D fold_build2 (MEM_REF, al_load_type, addr_tmp, > load_offset_ptr); >=20 > or keep track of the "first" actual load and use >=20 > unsigned int align =3D get_object_alignment (that_first_load); >=20 > "first" in the one that corresponds to addr_tmp. From that there > is a much better chance to derive good alignment values. >=20 > Of course on STRICT_ALIGNMENT targets a not aligned load > will be decomposed again, so eventually doing the transformation > may no longer be profitable(?). Not always decomposed. On MIPS, it should using the load/store left/right i= nstructions for unaligned load/stores which is normally better than decompo= sed load/stores. So having a cost model would be nice.=20 Thanks, Andrew >=20 > Thanks and sorry again for the delay. >=20 > Otherwise the patch looks good to me. >=20 > Richard. >=20 >>> Best regards, >>>=20 >>> Thomas >>>=20 >>>> -----Original Message----- >>>> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches- >>>> owner@gcc.gnu.org] On Behalf Of Thomas Preud'homme >>>> Sent: Monday, May 05, 2014 7:30 PM >>>> To: GCC Patches >>>> Subject: RE: [PATCH][2/3] Fix PR54733 Optimize endian independent >>>> load/store >>>>=20 >>>> I found a way to improve the function find_bswap/find_bswap_or_nop >>>> and reduce its size. Please hold for the review, I will post an updated >>>> version as soon as I finish testing. >>>>=20 >>>> Best regards, >>>>=20 >>>> Thomas Preud'homme >>=20 >>=20