From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57547 invoked by alias); 3 Oct 2016 13:02:15 -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 57533 invoked by uid 89); 3 Oct 2016 13:02:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=mailer, xxxxx, dance, quantity X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Oct 2016 13:02:08 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1F8CE29; Mon, 3 Oct 2016 06:02:06 -0700 (PDT) Received: from [10.2.207.77] (e100706-lin.cambridge.arm.com [10.2.207.77]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A31CC3F21A; Mon, 3 Oct 2016 06:02:05 -0700 (PDT) Message-ID: <57F256CC.4010403@foss.arm.com> Date: Mon, 03 Oct 2016 13:02:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Richard Biener CC: GCC Patches Subject: Re: [PATCH][v4] GIMPLE store merging pass References: <57EBE7A6.3040103@foss.arm.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00066.txt.bz2 Hi Richard, another question as I'm working through your comments... On 29/09/16 11:45, Richard Biener wrote: > >> + /* The region from the byte array that we're inserting into. */ >> + tree ptr_wide_int >> + = native_interpret_expr (dest_int_type, ptr + first_byte, >> + total_bytes); >> + >> + gcc_assert (ptr_wide_int); >> + wide_int dest_wide_int >> + = wi::to_wide (ptr_wide_int, TYPE_PRECISION (dest_int_type)); >> + wide_int expr_wide_int >> + = wi::to_wide (tmp_int, byte_size * BITS_PER_UNIT); >> + if (BYTES_BIG_ENDIAN) >> + { >> + unsigned int insert_pos >> + = byte_size * BITS_PER_UNIT - bitlen - (bitpos % BITS_PER_UNIT); >> + dest_wide_int >> + = wi::insert (dest_wide_int, expr_wide_int, insert_pos, bitlen); >> + } >> + else >> + dest_wide_int = wi::insert (dest_wide_int, expr_wide_int, >> + bitpos % BITS_PER_UNIT, bitlen); >> + >> + tree res = wide_int_to_tree (dest_int_type, dest_wide_int); >> + native_encode_expr (res, ptr + first_byte, total_bytes, 0); >> + > OTOH this whole dance looks as complicated and way more expensive than > using native_encode_expr into a temporary buffern and then a > manually implemented "bit-merging" of it at ptr + first_byte + bitpos. > AFAICS that operation is even endianess agnostic. If the quantity we're inserting at a non-byte boundary is more than a byte wide we still have to shift the value to position properly across the bytes it straddles, so I don't see how we can avoid creating a wide_int here. Consider inserting a 10-bit value at bitposition 3 (I hope the mailer doesn't screw up the indentation): value: xxxxxxxxxx before: |--------||--------| | byte 1 || byte 2 | after: |---xxxxx||xxxxx---| We'll native_encode_expr the value into a two-byte buffer but then we can't just shift each byte by 3 to insert it into the destination buffer, we need to form the whole 10-bit value and shift is as a whole to not lose any bits. And if a value crosses bytes then we need to care about BYTES_BIG_ENDIAN when writing the bytes back into the buffer, no? Thanks, Kyrill