* [PATCH] expand description of poly_int conversions
@ 2018-02-26 18:08 Martin Sebor
2018-02-26 19:45 ` Richard Sandiford
0 siblings, 1 reply; 5+ messages in thread
From: Martin Sebor @ 2018-02-26 18:08 UTC (permalink / raw)
To: richard.sandiford, Gcc Patch List
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
Richard,
If you agree, I'd like to update the conversion section of
the poly_int manual to make the conversion to make it clearer
that the to_constant() function can be used even with class
types like offset_int besides scalars.
Also, when testing this I also tried converting poly64_int
into wide_int but that doesn't work. Is there a way to do
that?
Thanks
Martin
[-- Attachment #2: gcc-poly-int-conversion.diff --]
[-- Type: text/x-patch, Size: 1247 bytes --]
gcc/ChangeLog:
* doc/poly-int.texi (is_constant): Expand.
Index: gcc/doc/poly-int.texi
===================================================================
--- gcc/doc/poly-int.texi (revision 258004)
+++ gcc/doc/poly-int.texi (working copy)
@@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co
@item @var{value}.is_constant (&@var{c1})
Return true if @code{poly_int} @var{value} is a compile-time constant,
-storing it in @var{c1} if so. @var{c1} must be able to hold all
-constant values of @var{value} without loss of precision.
+storing it in @var{c1} if so. @var{c1} may be a scalar or a wide int
+class type capable of holding all constant values of @var{value} without
+loss of precision. The following example illustrates using the function
+to convert a @code{poly64_int} to @code{HOST_WIDE_INT} and to
+@code{offset_int}.
+@smallexample
+void f (poly64_int pi)
+@{
+ HOST_WIDE_INT hwi;
+ if (pi.is_constant (&hwi))
+ ; // Use hwi...
+ offset_int off;
+ if (pi.is_constant (&off))
+ ; // Use off...
+@}
+@end smallexample
+
@item @var{value}.to_constant ()
Assert that @var{value} is a compile-time constant and return its value.
When using this function, please add a comment explaining why the
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] expand description of poly_int conversions
2018-02-26 18:08 [PATCH] expand description of poly_int conversions Martin Sebor
@ 2018-02-26 19:45 ` Richard Sandiford
2018-02-26 20:20 ` Martin Sebor
0 siblings, 1 reply; 5+ messages in thread
From: Richard Sandiford @ 2018-02-26 19:45 UTC (permalink / raw)
To: Martin Sebor; +Cc: Gcc Patch List
Martin Sebor <msebor@gmail.com> writes:
> Richard,
>
> If you agree, I'd like to update the conversion section of
> the poly_int manual to make the conversion to make it clearer
> that the to_constant() function can be used even with class
> types like offset_int besides scalars.
>
> Also, when testing this I also tried converting poly64_int
> into wide_int but that doesn't work. Is there a way to do
> that?
Not in one go, because you have to specify the intended precision
of the wide_int when constructing it from something like HOST_WIDE_INT.
(That's deliberate.)
>
> Thanks
> Martin
>
> gcc/ChangeLog:
>
> * doc/poly-int.texi (is_constant): Expand.
>
> Index: gcc/doc/poly-int.texi
> ===================================================================
> --- gcc/doc/poly-int.texi (revision 258004)
> +++ gcc/doc/poly-int.texi (working copy)
> @@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co
>
> @item @var{value}.is_constant (&@var{c1})
> Return true if @code{poly_int} @var{value} is a compile-time constant,
> -storing it in @var{c1} if so. @var{c1} must be able to hold all
> -constant values of @var{value} without loss of precision.
> +storing it in @var{c1} if so. @var{c1} may be a scalar or a wide int
> +class type capable of holding all constant values of @var{value} without
Not sure about "a scalar or a wide int", since that implies that wide ints
aren't scalar. Even more pedantic, sorry, but c1 is an object rather than
a type.
At a higher level, I'm a bit nervous about singling this out as a special
case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
wide_int to be combined in the (hopefully) natural way. E.g. you can
add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
and so on.
But if we do keep it like this, how about:
@var{c1} must be some form of integer object that can hold all constant
values of @var{value} without loss of precision; it can be either a normal
C++ integer or a wide-int class like @code{offset_int}.
?
> +loss of precision. The following example illustrates using the function
> +to convert a @code{poly64_int} to @code{HOST_WIDE_INT} and to
> +@code{offset_int}.
> +@smallexample
> +void f (poly64_int pi)
poly_int64
> +@{
> + HOST_WIDE_INT hwi;
> + if (pi.is_constant (&hwi))
> + ; // Use hwi...
> + offset_int off;
> + if (pi.is_constant (&off))
> + ; // Use off...
> +@}
> +@end smallexample
>
> +
> @item @var{value}.to_constant ()
> Assert that @var{value} is a compile-time constant and return its value.
> When using this function, please add a comment explaining why the
No need for the extra blank line.
Thanks,
Richard
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] expand description of poly_int conversions
2018-02-26 19:45 ` Richard Sandiford
@ 2018-02-26 20:20 ` Martin Sebor
2018-02-26 21:09 ` Richard Sandiford
0 siblings, 1 reply; 5+ messages in thread
From: Martin Sebor @ 2018-02-26 20:20 UTC (permalink / raw)
To: Gcc Patch List, richard.sandiford
[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]
On 02/26/2018 12:45 PM, Richard Sandiford wrote:
> Martin Sebor <msebor@gmail.com> writes:
>> Richard,
>>
>> If you agree, I'd like to update the conversion section of
>> the poly_int manual to make the conversion to make it clearer
>> that the to_constant() function can be used even with class
>> types like offset_int besides scalars.
>>
>> Also, when testing this I also tried converting poly64_int
>> into wide_int but that doesn't work. Is there a way to do
>> that?
>
> Not in one go, because you have to specify the intended precision
> of the wide_int when constructing it from something like HOST_WIDE_INT.
> (That's deliberate.)
>
>>
>> Thanks
>> Martin
>>
>> gcc/ChangeLog:
>>
>> * doc/poly-int.texi (is_constant): Expand.
>>
>> Index: gcc/doc/poly-int.texi
>> ===================================================================
>> --- gcc/doc/poly-int.texi (revision 258004)
>> +++ gcc/doc/poly-int.texi (working copy)
>> @@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co
>>
>> @item @var{value}.is_constant (&@var{c1})
>> Return true if @code{poly_int} @var{value} is a compile-time constant,
>> -storing it in @var{c1} if so. @var{c1} must be able to hold all
>> -constant values of @var{value} without loss of precision.
>> +storing it in @var{c1} if so. @var{c1} may be a scalar or a wide int
>> +class type capable of holding all constant values of @var{value} without
>
> Not sure about "a scalar or a wide int", since that implies that wide ints
> aren't scalar. Even more pedantic, sorry, but c1 is an object rather than
> a type.
>
> At a higher level, I'm a bit nervous about singling this out as a special
> case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
> wide_int to be combined in the (hopefully) natural way. E.g. you can
> add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
> and so on.
>
> But if we do keep it like this, how about:
>
> @var{c1} must be some form of integer object that can hold all constant
> values of @var{value} without loss of precision; it can be either a normal
> C++ integer or a wide-int class like @code{offset_int}.
>
> ?
Sure. Attached is an update with your change.
Martin
[-- Attachment #2: gcc-poly-int-conversion.diff --]
[-- Type: text/x-patch, Size: 1251 bytes --]
gcc/ChangeLog:
* doc/poly-int.texi (is_constant): Expand.
Index: gcc/doc/poly-int.texi
===================================================================
--- gcc/doc/poly-int.texi (revision 258004)
+++ gcc/doc/poly-int.texi (working copy)
@@ -836,8 +836,23 @@ Return true if @code{poly_int} @var{value} is a co
@item @var{value}.is_constant (&@var{c1})
Return true if @code{poly_int} @var{value} is a compile-time constant,
-storing it in @var{c1} if so. @var{c1} must be able to hold all
-constant values of @var{value} without loss of precision.
+storing it in @var{c1} if so. @var{c1} must be some form of integer
+object that can hold all constant values of @var{value} without loss
+of precision; it can be either a normal C++ integer or a wide-int class
+like @code{offset_int}. The following example illustrates using
+the function to convert a @code{poly_int64} to @code{HOST_WIDE_INT}
+and to @code{offset_int}.
+@smallexample
+void f (poly_int64 pi)
+@{
+ HOST_WIDE_INT hwi;
+ if (pi.is_constant (&hwi))
+ ; // Use hwi...
+ offset_int off;
+ if (pi.is_constant (&off))
+ ; // Use off...
+@}
+@end smallexample
@item @var{value}.to_constant ()
Assert that @var{value} is a compile-time constant and return its value.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] expand description of poly_int conversions
2018-02-26 20:20 ` Martin Sebor
@ 2018-02-26 21:09 ` Richard Sandiford
2018-02-28 23:14 ` Jeff Law
0 siblings, 1 reply; 5+ messages in thread
From: Richard Sandiford @ 2018-02-26 21:09 UTC (permalink / raw)
To: Martin Sebor; +Cc: Gcc Patch List
Martin Sebor <msebor@gmail.com> writes:
> On 02/26/2018 12:45 PM, Richard Sandiford wrote:
>> Martin Sebor <msebor@gmail.com> writes:
>>> Richard,
>>>
>>> If you agree, I'd like to update the conversion section of
>>> the poly_int manual to make the conversion to make it clearer
>>> that the to_constant() function can be used even with class
>>> types like offset_int besides scalars.
>>>
>>> Also, when testing this I also tried converting poly64_int
>>> into wide_int but that doesn't work. Is there a way to do
>>> that?
>>
>> Not in one go, because you have to specify the intended precision
>> of the wide_int when constructing it from something like HOST_WIDE_INT.
>> (That's deliberate.)
>>
>>>
>>> Thanks
>>> Martin
>>>
>>> gcc/ChangeLog:
>>>
>>> * doc/poly-int.texi (is_constant): Expand.
>>>
>>> Index: gcc/doc/poly-int.texi
>>> ===================================================================
>>> --- gcc/doc/poly-int.texi (revision 258004)
>>> +++ gcc/doc/poly-int.texi (working copy)
>>> @@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co
>>>
>>> @item @var{value}.is_constant (&@var{c1})
>>> Return true if @code{poly_int} @var{value} is a compile-time constant,
>>> -storing it in @var{c1} if so. @var{c1} must be able to hold all
>>> -constant values of @var{value} without loss of precision.
>>> +storing it in @var{c1} if so. @var{c1} may be a scalar or a wide int
>>> +class type capable of holding all constant values of @var{value} without
>>
>> Not sure about "a scalar or a wide int", since that implies that wide ints
>> aren't scalar. Even more pedantic, sorry, but c1 is an object rather than
>> a type.
>>
>> At a higher level, I'm a bit nervous about singling this out as a special
>> case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
>> wide_int to be combined in the (hopefully) natural way. E.g. you can
>> add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
>> and so on.
>>
>> But if we do keep it like this, how about:
>>
>> @var{c1} must be some form of integer object that can hold all constant
>> values of @var{value} without loss of precision; it can be either a normal
>> C++ integer or a wide-int class like @code{offset_int}.
>>
>> ?
>
> Sure. Attached is an update with your change.
LGTM (but I can't approve).
Thanks,
Richard
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] expand description of poly_int conversions
2018-02-26 21:09 ` Richard Sandiford
@ 2018-02-28 23:14 ` Jeff Law
0 siblings, 0 replies; 5+ messages in thread
From: Jeff Law @ 2018-02-28 23:14 UTC (permalink / raw)
To: Martin Sebor, Gcc Patch List, richard.sandiford
On 02/26/2018 02:09 PM, Richard Sandiford wrote:
> Martin Sebor <msebor@gmail.com> writes:
>> On 02/26/2018 12:45 PM, Richard Sandiford wrote:
>>> Martin Sebor <msebor@gmail.com> writes:
>>>> Richard,
>>>>
>>>> If you agree, I'd like to update the conversion section of
>>>> the poly_int manual to make the conversion to make it clearer
>>>> that the to_constant() function can be used even with class
>>>> types like offset_int besides scalars.
>>>>
>>>> Also, when testing this I also tried converting poly64_int
>>>> into wide_int but that doesn't work. Is there a way to do
>>>> that?
>>>
>>> Not in one go, because you have to specify the intended precision
>>> of the wide_int when constructing it from something like HOST_WIDE_INT.
>>> (That's deliberate.)
>>>
>>>>
>>>> Thanks
>>>> Martin
>>>>
>>>> gcc/ChangeLog:
>>>>
>>>> * doc/poly-int.texi (is_constant): Expand.
>>>>
>>>> Index: gcc/doc/poly-int.texi
>>>> ===================================================================
>>>> --- gcc/doc/poly-int.texi (revision 258004)
>>>> +++ gcc/doc/poly-int.texi (working copy)
>>>> @@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co
>>>>
>>>> @item @var{value}.is_constant (&@var{c1})
>>>> Return true if @code{poly_int} @var{value} is a compile-time constant,
>>>> -storing it in @var{c1} if so. @var{c1} must be able to hold all
>>>> -constant values of @var{value} without loss of precision.
>>>> +storing it in @var{c1} if so. @var{c1} may be a scalar or a wide int
>>>> +class type capable of holding all constant values of @var{value} without
>>>
>>> Not sure about "a scalar or a wide int", since that implies that wide ints
>>> aren't scalar. Even more pedantic, sorry, but c1 is an object rather than
>>> a type.
>>>
>>> At a higher level, I'm a bit nervous about singling this out as a special
>>> case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
>>> wide_int to be combined in the (hopefully) natural way. E.g. you can
>>> add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
>>> and so on.
>>>
>>> But if we do keep it like this, how about:
>>>
>>> @var{c1} must be some form of integer object that can hold all constant
>>> values of @var{value} without loss of precision; it can be either a normal
>>> C++ integer or a wide-int class like @code{offset_int}.
>>>
>>> ?
>>
>> Sure. Attached is an update with your change.
>
> LGTM (but I can't approve).
That, IMHO, is a technicality :-) You know these bits better than
anyone. So if you're OK with them, that's good enough for me :-)
Rubber-stamped for the trunk.
jeff
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-02-28 23:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-26 18:08 [PATCH] expand description of poly_int conversions Martin Sebor
2018-02-26 19:45 ` Richard Sandiford
2018-02-26 20:20 ` Martin Sebor
2018-02-26 21:09 ` Richard Sandiford
2018-02-28 23:14 ` Jeff Law
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).