Performing inter-procedural dataflow analysis

Performing inter-procedural dataflow analysis

[Shuai Wang]

Hello,

I am doing interprocedural dataflow analysis and countered the following
issue. Suppose I have an GIMPLE IR code as follows, which is after the
"simdclone" pass while before my own SIMPLE IPA pass:


foo (int a, int b)
{
  int c;
  int d;
  int D.2425;
  int _5;

  <bb 2> :
*  c_4 = a_2(D) + b_3(D);  *
*  _5 = c_4;*
  ....

As you can see, while propagating certain dataflow facts among local
variables are smooth (e.g., from c_4 --> c_4 --> _5), I can hardly somehow
"link" function parameter "a" (or "b") with its first local usage "a_2(D)"
or "b_3(D)".

So my question is, when traversing the GIMPLE statements and encounter SSA
variables like "a_2(D)" or "b_3(D)", how do I know they originate from
parameter "a" and "b"?

Thank you!

Best,
Shuai

Re: Performing inter-procedural dataflow analysis

[Shuai Wang]

By saying a_2(D) originated from parameter "a", what I mean is that I
obtain the tree pointer of "a" given the tree pointer of a_2(D). Is that
possible? I can somehow image to first get the string name of these
variables and do a clumsy (?) comparison. But that seems not very handy...

Thank you!


On Thu, Feb 18, 2021 at 11:09 AM Shuai Wang <wangshuai901@gmail.com> wrote:

> Hello,
>
> I am doing interprocedural dataflow analysis and countered the following
> issue. Suppose I have an GIMPLE IR code as follows, which is after the
> "simdclone" pass while before my own SIMPLE IPA pass:
>
>
> foo (int a, int b)
> {
>   int c;
>   int d;
>   int D.2425;
>   int _5;
>
>   <bb 2> :
> *  c_4 = a_2(D) + b_3(D);  *
> *  _5 = c_4;*
>   ....
>
> As you can see, while propagating certain dataflow facts among local
> variables are smooth (e.g., from c_4 --> c_4 --> _5), I can hardly
> somehow "link" function parameter "a" (or "b") with its first local usage
> "a_2(D)" or "b_3(D)".
>
> So my question is, when traversing the GIMPLE statements and encounter SSA
> variables like "a_2(D)" or "b_3(D)", how do I know they originate from
> parameter "a" and "b"?
>
> Thank you!
>
> Best,
> Shuai
>
>
>
>

Re: Performing inter-procedural dataflow analysis

[Prathamesh Kulkarni]

On Thu, 18 Feb 2021 at 08:39, Shuai Wang via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hello,
>
> I am doing interprocedural dataflow analysis and countered the following
> issue. Suppose I have an GIMPLE IR code as follows, which is after the
> "simdclone" pass while before my own SIMPLE IPA pass:
>
>
> foo (int a, int b)
> {
>   int c;
>   int d;
>   int D.2425;
>   int _5;
>
>   <bb 2> :
> *  c_4 = a_2(D) + b_3(D);  *
> *  _5 = c_4;*
>   ....
>
> As you can see, while propagating certain dataflow facts among local
> variables are smooth (e.g., from c_4 --> c_4 --> _5), I can hardly somehow
> "link" function parameter "a" (or "b") with its first local usage "a_2(D)"
> or "b_3(D)".
>
> So my question is, when traversing the GIMPLE statements and encounter SSA
> variables like "a_2(D)" or "b_3(D)", how do I know they originate from
> parameter "a" and "b"?
You can use SSA_NAME_VAR to get the "base" variable corresponding to ssa name,
and then check it against PARM_DECL.
Sth like:
is_param = TREE_CODE (SSA_NAME_VAR (ssa_name)) == PARM_DECL;

Thanks,
Prathamesh
>
> Thank you!
>
> Best,
> Shuai

Re: Performing inter-procedural dataflow analysis

[Martin Jambor]

Hi,

On Thu, Feb 18 2021, Shuai Wang via Gcc wrote:
> Hello,
>
> I am doing interprocedural dataflow analysis and countered the following
> issue. Suppose I have an GIMPLE IR code as follows, which is after the
> "simdclone" pass while before my own SIMPLE IPA pass:
>
>
> foo (int a, int b)
> {
>   int c;
>   int d;
>   int D.2425;
>   int _5;
>
>   <bb 2> :
> *  c_4 = a_2(D) + b_3(D);  *
> *  _5 = c_4;*
>   ....
>
> As you can see, while propagating certain dataflow facts among local
> variables are smooth (e.g., from c_4 --> c_4 --> _5), I can hardly somehow
> "link" function parameter "a" (or "b") with its first local usage "a_2(D)"
> or "b_3(D)".

are you perhaps looking for function ssa_default_def (defined in tree-dfa.c)?

>
> So my question is, when traversing the GIMPLE statements and encounter SSA
> variables like "a_2(D)" or "b_3(D)", how do I know they originate from
> parameter "a" and "b"?

You check that SSA_NAME_IS_DEFAULT_DEF is true (and that their
SSA_NAME_VAR is the PARM_DECL you are after).

Martin