On Thu, May 14, 2020 at 6:00 AM 易会战 <huizha...@foxmail.com> wrote:
>
> There are some other cases that I cannot get right answer.
> case1: interproceduure
> func(int*arg)
> {
> return arg[0] + arg[1]
> }
> func2()
> {
> int a[10]
> return func(a);
> }
> here func cannot tell arg is local var.
>
> case 2: global array point to local
> int *array[3]
> int func(int x)
> {
> int sub1[10];
> int sub2[10];
> int sub3[10];
> array[0] = sub1;
> array[1]=sub2;
> array[2]=sub3;
> then refer to array by array[x][y]
> }
> here i refer to local var, but the points-to cannnot give right answer.
>
> I do not know if this is the points-to analysis problem, or improper use it.
GCCs analysis is not powerful enough to provide "right" answers you
are seeking for. GCCs analysis provides conservative correct answers
for the users it has though which is alias analysis.
Richard.
> ---Original---
> From: "Richard Biener"<richard.guent...@gmail.com>
> Date: Wed, May 13, 2020 19:10 PM
> To: "易会战"<huizha...@foxmail.com>;
> Cc: "gcc"<gcc@gcc.gnu.org>;
> Subject: Re: how to find variable related to a virtual ssa name
>
> On Wed, May 13, 2020 at 11:38 AM 易会战 <huizha...@foxmail.com> wrote:
> >
> > now I am working on gcc-9.3, can you give the specific code location to
> > check not escaped heap? I try to add a flag.
>
> set_uids_in_ptset
>
> > ---Original---
> > From: "Richard Biener"<richard.guent...@gmail.com>
> > Date: Wed, May 13, 2020 17:28 PM
> > To: "易会战"<huizha...@foxmail.com>;
> > Cc: "gcc"<gcc@gcc.gnu.org>;
> > Subject: Re: how to find variable related to a virtual ssa name
> >
> > On Wed, May 13, 2020 at 11:08 AM 易会战 <huizha...@foxmail.com> wrote:
> > >
> > > yes, it does not escape the function, but indeed allocate memory on heap.
> > > There is much specific method to judge the memory on heap although not
> > > escape the function?
> >
> > Not at the moment. The info is computed by tree-ssa-structalias.c in
> > compute_may_aliases,
> > the pass knows that a variable points to not escaped heap storage but this
> > is
> > not stored anywhere ready for consumption. Adding a flag to
> > pt_solution would be easy though.
> >
> > Richard.
> >
> > > ---Original---
> > > From: "Richard Biener"<richard.guent...@gmail.com>
> > > Date: Wed, May 13, 2020 15:00 PM
> > > To: "易会战"<huizha...@foxmail.com>;
> > > Cc: "gcc"<gcc@gcc.gnu.org>;
> > > Subject: Re: how to find variable related to a virtual ssa name
> > >
> > > On Wed, May 13, 2020 at 6:03 AM 易会战 <huizha...@foxmail.com> wrote:
> > > >
> > > > It seems the function ptr_deref_may_alias_global_p cannot give right
> > > > result.
> > > > For example,
> > > > int func(int size, int i)
> > > > {
> > > > int * sum;
> > > > sum = malloc()
> > > > ....here some code access sum pointing to memory
> > > > return sum[i]
> > > > }
> > > > ptr_deref_may_alias_global_p tell me it is a local memory access.
> > > > indeed sum is a local variable, but the pointer point to heap memory.
> > > > In fact there is a similiar function ref_may_alias_global_p, and it
> > > > give similiar result.
> > >
> > > GCC can be clever and notice your malloc() result does not escape the
> > > function
> > > which means stores to it are dead once you leave it. For this reason
> > > it does not
> > > mark the memory global. So make sure the allocated pointer escapes
> > > and try again.
> > >
> > > >
> > > >
> > > > ---Original---
> > > > From: "Richard Biener"<richard.guent...@gmail.com>
> > > > Date: Tue, May 12, 2020 22:20 PM
> > > > To: "易会战"<huizha...@foxmail.com>;
> > > > Cc: "gcc"<gcc@gcc.gnu.org>;
> > > > Subject: Re: how to find variable related to a virtual ssa name
> > > >
> > > > On Tue, May 12, 2020 at 4:16 PM 易会战 <huizha...@foxmail.com> wrote:
> > > > >
> > > > > thanks a lot. I will check your advice.
> > > > > Can you give some explaination about memory ssa, and how to use it. I
> > > > > check internal, cannot get it. Maybe you know some examples or some
> > > > > more materials.
> > > >
> > > > memory SSA in GCC is simply a SSA chain of all memory statements local
> > > > to a function
> > > > with a _single_ underlying variable (.MEM) and thus only one SSA name
> > > > live at the same
> > > > time. It can be used to quickly traverse stores via use->def chains
> > > > and loads inbetween
> > > > two stores via immediate uses.
> > > >
> > > > Richard.
> > > >
> > > > > ---Original---
> > > > > From: "Richard Biener"<richard.guent...@gmail.com>
> > > > > Date: Tue, May 12, 2020 22:02 PM
> > > > > To: "易会战"<huizha...@foxmail.com>;
> > > > > Cc: "gcc"<gcc@gcc.gnu.org>;
> > > > > Subject: Re: how to find variable related to a virtual ssa name
> > > > >
> > > > > On Tue, May 12, 2020 at 2:44 PM 易会战 via Gcc <gcc@gcc.gnu.org> wrote:
> > > > > >
> > > > > > hi, I am working on gcc ssa name. For each function, we can
> > > > > > traverse all defined ssa name by macro FOR_EACH_SSA_NAME. If a ssa
> > > > > > name is default definition for a symbol (check
> > > > > > SSA_NAME_IS_DEFAULT_DEF) , I can get the symbol by SSA_NAME_VAR.
> > > > > > But for a virtual DEFAULT DEF, I cannot get it, SSA_NAME_VAR return
> > > > > > a identifier named .MEM. I cannot find which variable related to
> > > > > > the default definition. Why and how I should find the related
> > > > > > variable?
> > > > > >
> > > > > >
> > > > > > By the way , I give my current work, I wish find a MEM_REF
> > > > > > refer to global/heap memory or local stack. I try my best to get a
> > > > > > correct memory type. Since MEM_REF have a base address, which is
> > > > > > often a ssa name. Athough it is not virtual ssa name. But I find
> > > > > > just check ssa name data flow is not enough to get the info.
> > > > > > For example, a malloc function allocate some heap memory and record
> > > > > > the address in a global ptr. On gimple ssa IR, the malloc function
> > > > > > return a address assigned to a ssa name , then ssa name assign the
> > > > > > value to the global ptr. When i check ssa name defined by the
> > > > > > global ptr, I donot know if the ptr point to global memory or local
> > > > > > memory.
> > > > > > Please see the gimple code:
> > > > > > _2 = malloc()
> > > > > > ptr = _2
> > > > > > _3 = ptr
> > > > > > MEM_REF[BASE _3]
> > > > > > I wish get _3 is a address pointing to global memory. But
> > > > > > just from _3=ptr, cannot judge it.
> > > > > > I wish memory SSA can help solve the problem.
> > > > >
> > > > > memory SSA will not solve this problem. You can instead query
> > > > > points-to information
> > > > > on _3 for example by calling ptr_deref_may_alias_global_p (_3) which
> > > > > internally
> > > > > looks at SSA_NAME_PTR_INFO which contains the solution of the
> > > > > points-to computation.
> > > > >
> > > > > Richard.
> > > > >
> > > > > >
> > > > > > Or gcc gives the info at other pass? wish get some advice. Thanks a
> > > > > > lot.
