Question on ipa-bit-cp and pointer_plus_expr

Question on ipa-bit-cp and pointer_plus_expr

[Erick Ochoa]

Hello,

I'm trying to understand ipa-bit-cp/ipa-cp and how the known bits are
propagated to the lattice in the case of a pointer_plus_expr.

I have a piece of code similar to the following (this being a simplified
example)

int main ()
{
  // a = some pointer.
  foo (a);
}

foo (void* a)
{
  bar (a + 1);
}

bar (void *a) {}

I have the following ipa-cp dump:

callsite main -> foo
param 0: UNKNOWN
     value: 0x0, mask 0xfffffffffffffff8


as it is passed to bar I have the following:

callsite foo -> bar
param 0: PASS THROUGH: 0, op poiner_plus_expr 8
  value: 0x0, mask 0xffffffffffffffff

My question is, shouldn't the mask to bar be 0xfffffffffffffff8?

If I understand correctly the mask being 0xfffffffffffffff8 implies that
the value will be a multiple of 8. By adding 8 (or any multiple of 8) to
it, it should still be a multiple of 8. Where I believe the mask becomes
0xffffffffffffffff is that during the addition there might be an overflow
of the masks and the operand 8. But I am still unsure. Can someone point
out what is happening here?

Thanks!

Re: Question on ipa-bit-cp and pointer_plus_expr

[Martin Jambor]

Hi,

On Thu, Feb 17 2022, Erick Ochoa via Gcc wrote:
> Hello,
>
> I'm trying to understand ipa-bit-cp/ipa-cp and how the known bits are
> propagated to the lattice in the case of a pointer_plus_expr.
>
> I have a piece of code similar to the following (this being a simplified
> example)
>
> int main ()
> {
>   // a = some pointer.
>   foo (a);
> }
>
> foo (void* a)
> {
>   bar (a + 1);
> }
>
> bar (void *a) {}
>
> I have the following ipa-cp dump:
>
> callsite main -> foo
> param 0: UNKNOWN
>      value: 0x0, mask 0xfffffffffffffff8
>
>
> as it is passed to bar I have the following:
>
> callsite foo -> bar
> param 0: PASS THROUGH: 0, op poiner_plus_expr 8
>   value: 0x0, mask 0xffffffffffffffff
>
> My question is, shouldn't the mask to bar be 0xfffffffffffffff8?
>
> If I understand correctly the mask being 0xfffffffffffffff8 implies that
> the value will be a multiple of 8. By adding 8 (or any multiple of 8) to
> it, it should still be a multiple of 8. Where I believe the mask becomes
> 0xffffffffffffffff is that during the addition there might be an overflow
> of the masks and the operand 8. But I am still unsure. Can someone point
> out what is happening here?

If you do not use LTO, foo and bar must be static for IPA-CP to
determine that their arguments are aligned - and correctly so, if there
are unknown callers passing unknown values, we cannot assume anything.
With LTO or them being static, IPA-CP can do so.

But make sure you understand that different things in the dump mean
different stuff, you will not find any propagated values in the
jump-function dump which you quoted, those really just describe the call
without any larger context.  For results of propagation you need to look
into the "Lattices" section of the dump.

Martin

Re: Question on ipa-bit-cp and pointer_plus_expr

[Erick Ochoa]

Thanks Martin!

The example I showed is simplified and I had not specified that I was using
LTO, but I am. Thanks for asking me to clarify this.

The issue I have with the information in the Lattice section of the dump is
that it shows the information once the analysis has achieved a fixed point.
However, the example is a bit more complicated. There is a recursive call
in bar and some pointer manipulation which will for sure remove the static
information that the incoming parameter to bar is a multiple of 8.

bar (void *a) {
  // some pointer manipulation
  a = // pointer manipulation based on a, casts to (char*) arithmetic...
  bar (a);
}

However, I am mostly interested in the static information available at the
callsite foo -> bar and not on the incoming static information available at
the parameter "a" of bar. Does this make sense?

Is there a place where I can look at the static information available at
the argument and not the parameter?

Thanks!

On Thu, 17 Feb 2022 at 17:25, Martin Jambor <mjambor@suse.cz> wrote:

> Hi,
>
> On Thu, Feb 17 2022, Erick Ochoa via Gcc wrote:
> > Hello,
> >
> > I'm trying to understand ipa-bit-cp/ipa-cp and how the known bits are
> > propagated to the lattice in the case of a pointer_plus_expr.
> >
> > I have a piece of code similar to the following (this being a simplified
> > example)
> >
> > int main ()
> > {
> >   // a = some pointer.
> >   foo (a);
> > }
> >
> > foo (void* a)
> > {
> >   bar (a + 1);
> > }
> >
> > bar (void *a) {}
> >
> > I have the following ipa-cp dump:
> >
> > callsite main -> foo
> > param 0: UNKNOWN
> >      value: 0x0, mask 0xfffffffffffffff8
> >
> >
> > as it is passed to bar I have the following:
> >
> > callsite foo -> bar
> > param 0: PASS THROUGH: 0, op poiner_plus_expr 8
> >   value: 0x0, mask 0xffffffffffffffff
> >
> > My question is, shouldn't the mask to bar be 0xfffffffffffffff8?
> >
> > If I understand correctly the mask being 0xfffffffffffffff8 implies that
> > the value will be a multiple of 8. By adding 8 (or any multiple of 8) to
> > it, it should still be a multiple of 8. Where I believe the mask becomes
> > 0xffffffffffffffff is that during the addition there might be an overflow
> > of the masks and the operand 8. But I am still unsure. Can someone point
> > out what is happening here?
>
> If you do not use LTO, foo and bar must be static for IPA-CP to
> determine that their arguments are aligned - and correctly so, if there
> are unknown callers passing unknown values, we cannot assume anything.
> With LTO or them being static, IPA-CP can do so.
>
> But make sure you understand that different things in the dump mean
> different stuff, you will not find any propagated values in the
> jump-function dump which you quoted, those really just describe the call
> without any larger context.  For results of propagation you need to look
> into the "Lattices" section of the dump.
>
> Martin
>

Re: Question on ipa-bit-cp and pointer_plus_expr

[Martin Jambor]

Hi,

On Thu, Feb 17 2022, Erick Ochoa wrote:
> Thanks Martin!
>
> The example I showed is simplified and I had not specified that I was using
> LTO, but I am. Thanks for asking me to clarify this.
>
> The issue I have with the information in the Lattice section of the dump is
> that it shows the information once the analysis has achieved a fixed point.
> However, the example is a bit more complicated. There is a recursive call
> in bar and some pointer manipulation which will for sure remove the static
> information that the incoming parameter to bar is a multiple of 8.
>
> bar (void *a) {
>   // some pointer manipulation
>   a = // pointer manipulation based on a, casts to (char*) arithmetic...
>   bar (a);
> }
>
> However, I am mostly interested in the static information available at the
> callsite foo -> bar and not on the incoming static information available at
> the parameter "a" of bar. Does this make sense?
>
> Is there a place where I can look at the static information available at
> the argument and not the parameter?

If I understand you correctly, that is indeed the jump function,
obtainable through ipa_get_ith_jump_func (args, i) where args is a
result of ipa_edge_args_sum->get and i is the index of the parameter.

Martin

Re: Question on ipa-bit-cp and pointer_plus_expr

[Erick Ochoa]

> If I understand you correctly, that is indeed the jump function,
> obtainable through ipa_get_ith_jump_func (args, i) where args is a
> result of ipa_edge_args_sum->get and i is the index of the parameter.
>

Thanks Martin!

So then, am I correct in thinking that

callsite foo -> bar
param 0: PASS THROUGH: 0, op poiner_plus_expr 8
  value: 0x0, mask 0xffffffffffffffff

should be

callsite foo -> bar
param 0: PASS THROUGH: 0, op poiner_plus_expr 8
  value: 0x0, mask 0xfffffffffffffff8

?

Re: Question on ipa-bit-cp and pointer_plus_expr

[Martin Jambor]

Hi,

On Thu, Feb 17 2022, Erick Ochoa wrote:
>> If I understand you correctly, that is indeed the jump function,
>> obtainable through ipa_get_ith_jump_func (args, i) where args is a
>> result of ipa_edge_args_sum->get and i is the index of the parameter.
>>
>
> Thanks Martin!
>
> So then, am I correct in thinking that
>
> callsite foo -> bar
> param 0: PASS THROUGH: 0, op poiner_plus_expr 8
>   value: 0x0, mask 0xffffffffffffffff
>
> should be
>
> callsite foo -> bar
> param 0: PASS THROUGH: 0, op poiner_plus_expr 8
>   value: 0x0, mask 0xfffffffffffffff8
>

Ummm... no, it should not.  Jump functions just describe what can be
inferred about the parameter from the callers body, without any IPA
context (there is a caveat for inlined call graph nodes, but IPA-CP runs
before inlining).  And from the body of foo you do not know anything.

You can of course combine the jump function with the corresponding
lattice of the caller, like propagate_bits_across_jump_function does, to
get a better estimate, and you'll arrive at the value you seem to want.
I'm not sure if you tried your simple example, but it does.

Martin