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
prev parent 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).