Martin Sebor <mse...@gmail.com> writes:
> On 02/23/2018 01:13 PM, Jakub Jelinek wrote:
>> On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:
>>> + /* get_inner_reference is not expected to return null. */
>>> + gcc_assert (base != NULL);
>>> +
>>> poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
>>>
>>> - HOST_WIDE_INT const_off;
>>> - if (!base || !bytepos.is_constant (&const_off))
>>> - {
>>> - base = get_base_address (TREE_OPERAND (expr, 0));
>>> - return;
>>> - }
>>> -
>>> + /* There is no conversion from poly_int64 to offset_int even
>>> + though the latter is wider, so go through HOST_WIDE_INT.
>>> + The offset is expected to always be constant. */
>>> + HOST_WIDE_INT const_off = bytepos.to_constant ();
>>
>> The assert is ok, but removing the bytepos.is_constant (&const_off)
>> is wrong, I'm sure Richard S. can come up with some SVE testcase
>> where it will not be constant. If it is not constant, you can handle
>> it like var_off (which as I said on IRC or in the PR also seems to be
>> incorrect, because if the base is not a decl the variable offset could be
>> negative).
>
> That's what I did at first. I took it out because it sounded
> to me like you were saying it was a hypothetical possibility,
> not something that would ever happen in practice, and because
> I have no way of testing that code. I have put it back in
> the attached update.
>
> Since you added Richard: can you please explain how to convert
> a poly64_int to offset_int without converting it to HOST_WIDE_INT,
> or if it can't be done, why not? It's cumbersome and error-prone
> to have to go through HWI, and doing so defeats the main goal of
> using offset_int in the gimple-ssa-warn-restrict pass. Should
> the pass (and others like it) be changed to store offsets and
> sizes in some flavor of poly_int instead of offset_int?
Not sure if this is what you mean, but:
bool f (poly_int64 x, offset_int *y) { return x.is_constant (y); }
does work. "y" doesn't have to be "HOST_WIDE_INT *".
Richard
