public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH][v4] GIMPLE store merging pass
Date: Mon, 03 Oct 2016 16:43:00 -0000	[thread overview]
Message-ID: <CF5C5799-6DB5-4557-A80E-A8BD6007CD6E@suse.de> (raw)
In-Reply-To: <57F256CC.4010403@foss.arm.com>

On October 3, 2016 3:02:04 PM GMT+02:00, Kyrill Tkachov <kyrylo.tkachov@foss.arm.com> wrote:
>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.

Native encode will encode into a byte array in target representation / endianess.

I think you can work byte-wise by properly merging 'lost' bits from adjacent bytes.  And you at most need 2 of them per 'target byte'.

>And if a value crosses bytes then we need to care about
>BYTES_BIG_ENDIAN when
>writing the bytes back into the buffer, no?

If you shift a > byte size quantity on the host (wide-ints are in host endianess) then you indeed need to watch out for endianess.

But as we deal with target memory representation plus bit offsets into memory I think it's natural to work with bytes.

Richard.

>Thanks,
>Kyrill


      reply	other threads:[~2016-10-03 16:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-28 16:00 Kyrill Tkachov
2016-09-28 16:07 ` Bill Schmidt
2016-09-28 16:09   ` Kyrill Tkachov
2016-09-29 16:01   ` Pat Haugen
2016-09-29 16:10     ` Kyrill Tkachov
2016-09-28 17:32 ` Pat Haugen
2016-09-29  8:02   ` Richard Biener
2016-09-29  8:24     ` Kyrill Tkachov
2016-09-29 10:54 ` Richard Biener
2016-09-29 15:37   ` Kyrill Tkachov
2016-09-30  7:09     ` Richard Biener
2016-09-30 15:25   ` Kyrill Tkachov
2016-09-30 15:34     ` Kyrill Tkachov
2016-09-30 17:02       ` Richard Biener
2016-09-30 16:58   ` Kyrill Tkachov
2016-10-04  8:18     ` Richard Biener
2016-10-03 13:02   ` Kyrill Tkachov
2016-10-03 16:43     ` Richard Biener [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=CF5C5799-6DB5-4557-A80E-A8BD6007CD6E@suse.de \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kyrylo.tkachov@foss.arm.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).