From: Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>
To: Richard Biener <rguenther@suse.de>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH][v4] GIMPLE store merging pass
Date: Mon, 03 Oct 2016 13:02:00 -0000 [thread overview]
Message-ID: <57F256CC.4010403@foss.arm.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1609291133040.26629@t29.fhfr.qr>
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
next prev parent reply other threads:[~2016-10-03 13:02 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 [this message]
2016-10-03 16:43 ` Richard Biener
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=57F256CC.4010403@foss.arm.com \
--to=kyrylo.tkachov@foss.arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/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).