This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [021/nnn] poly_int: extract_bit_field bitrange
- From: Jeff Law <law at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org, richard dot sandiford at linaro dot org
- Date: Tue, 5 Dec 2017 16:46:36 -0700
- Subject: Re: [021/nnn] poly_int: extract_bit_field bitrange
- Authentication-results: sourceware.org; auth=none
- References: <871sltvm7r.fsf@linaro.org> <87d15drduy.fsf@linaro.org>
On 10/23/2017 11:08 AM, Richard Sandiford wrote:
> Similar to the previous store_bit_field patch, but for extractions
> rather than insertions. The patch splits out the extraction-as-subreg
> handling into a new function (extract_bit_field_as_subreg), both for
> ease of writing and because a later patch will add another caller.
>
> The simplify_gen_subreg overload is temporary; it goes away
> in a later patch.
>
>
> 2017-10-23 Richard Sandiford <richard.sandiford@linaro.org>
> Alan Hayward <alan.hayward@arm.com>
> David Sherwood <david.sherwood@arm.com>
>
> gcc/
> * rtl.h (simplify_gen_subreg): Add a temporary overload that
> accepts poly_uint64 offsets.
> * expmed.h (extract_bit_field): Take bitsize and bitnum as
> poly_uint64s rather than unsigned HOST_WIDE_INTs.
> * expmed.c (lowpart_bit_field_p): Likewise.
> (extract_bit_field_as_subreg): New function, split out from...
> (extract_bit_field_1): ...here. Take bitsize and bitnum as
> poly_uint64s rather than unsigned HOST_WIDE_INTs. For vector
> extractions, check that BITSIZE matches the size of the extracted
> value and that BITNUM is an exact multiple of that size.
> If all else fails, try forcing the value into memory if
> BITNUM is variable, and adjusting the address so that the
> offset is constant. Split the part that can only handle constant
> bitsize and bitnum out into...
> (extract_integral_bit_field): ...this new function.
> (extract_bit_field): Take bitsize and bitnum as poly_uint64s
> rather than unsigned HOST_WIDE_INTs.
OK.
jeff