This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: wide-int, rtl
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, Mike Stump <mikestump at comcast dot net>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 07 Dec 2013 10:28:20 +0000
- Subject: Re: wide-int, rtl
- Authentication-results: sourceware.org; auth=none
- References: <DA03AB53-E5E7-4B8D-9085-257FD158D7E8 at comcast dot net> <1673383 dot yVHhgiMuu2 at polaris> <52A23C51 dot 8040107 at naturalbridge dot com>
Kenneth Zadeck <zadeck@naturalbridge.com> writes:
>> + /* One could argue that GET_MODE_PRECISION (TYPE_MODE (type))
>> + should always be the same as TYPE_PRECISION (type).
>> + However, it is not. Since we are converting from tree to
>> + rtl, we have to expose this ugly truth here. */
>> + temp = immed_wide_int_const (wide_int::from
>> + (exp,
>> + GET_MODE_PRECISION (TYPE_MODE (type)),
>> + TYPE_SIGN (type)),
>> + TYPE_MODE (type));
>> + return temp;
>> + }
>>
>> I don't really see how one could argue that, given that there are much fewer
>> modes than possible type precisions, so please rewrite the comment, e.g.:
>>
>> "Given that TYPE_PRECISION (type) is not always equal to
>> GET_MODE_PRECISION (TYPE_MODE (type)), we need to extend from the former
>> to the latter according to the signedness of the type".
>>
>> What about a fast track where the precisions are indeed equal?
>>
>
> There is not really a faster track here. you still are starting with
> a tree and converting to an rtx. All that the default one would do
> would be to access the types precision and sign and use that.
FWIW it would be:
temp = immed_wide_int_const (exp, TYPE_MODE (type));
But it's hard to tell whether it would buy much. It didn't show up as
a hot spot when I was doing performance measurements before.
>> --- a/gcc/machmode.def
>> +++ b/gcc/machmode.def
>> @@ -229,6 +229,9 @@ UACCUM_MODE (USA, 4, 16, 16); /* 16.16 */
>> UACCUM_MODE (UDA, 8, 32, 32); /* 32.32 */
>> UACCUM_MODE (UTA, 16, 64, 64); /* 64.64 */
>>
>> +/* Should be overridden by EXTRA_MODES_FILE if wrong. */
>> +#define MAX_BITS_PER_UNIT 8
>> +
>>
>> What is it for? It's not documented at all.
>>
> This requires some discussion as to the direction we want to go. This is
> put in so that in gen_modes we can compute MAX_BITSIZE_MODE_ANY_INT and
> MAX_BITSIZE_MODE_ANY_MODE. The problem is that during genmodes we do
> have access to BITS_PER_UNIT. These two computed symbols are then
> used as compile time constants in other parts of the compiler to
> allocate data structures that are guaranteed to be large enough.
>
> Richard Sandiford put this in so we would preserve the ability to build
> a multi-targetted compiler where the targets had different values for
> BITS_PER_UNIT. So one possibility is that we add some documentation to
> this effect.
Sorry, I forgot yesterday an important detail behind why this seemed
like a good thing. I think there was a strong feeling (from me and others)
that wide-int.h shouldn't depend on tm.h. If we make wide-int.h depend
on tm.h then basically all the compiler does.
So as it stands we can't use BITS_PER_UNIT directly. Having a
MAX_BITS_PER_UNIT for "all compiled-in targets" (which obviously
as things stand is exactly one) seemed like a reasonable abstraction.
Alternatively we could say that BITS_PER_UNIT is really part of the
definition of QImode and move it to the modes.def file.
Thanks,
Richard