Thank you. Yes, I think gimple_store_p and gimple_assign_load_p should be
what I am looking for.
Best,
Shuai
On Tue, Jul 14, 2020 at 5:38 PM Richard Biener <richard.guent...@gmail.com>
wrote:
> On Tue, Jul 14, 2020 at 9:17 AM Shuai Wang via Gcc <gcc@gcc.gnu.org>
> wrote:
> >
> > Hello,
> >
> > I am trying to traverse the GIMPlE statements and identify all pointer
> > differences (i.e., memory load and store). For instance, something like:
> >
> > **_4* = 0;
> > ...
> > _108 = (signed char *) _107;
> > _109 = **_108*;
> >
> > After some quick searches in the GCC codebase, I am thinking to use the
> > following statements to identify variables like _4 and _108:
> >
> > tree op0 = gimple_op(stmt, 0); // get the left variable
>
> Use gimple_get_lhs (stmt)
>
> > if (TREE_CODE (op0) == SSA_NAME) {
> > struct ptr_info_def *pi = SSA_NAME_PTR_INFO (op0);
> > if (pi) {
>
> That's the wrong thing to look at. You can use gimple_store_p
> which also can end up with DECL_P in position op0.
>
> But what you are running into is that the LHS of *_4 = 0; is _not_
> the SSA name _4 but a MEM_REF tree with tree operand zero
> being the SSA name _4.
>
> > std::cerr << "find a store\n";
> > return STORE;
> > }
> > }
> >
> > However, to my surprise, variables like _4 just cannot be matched.
> Actually
> > _4 and _108 will be both treated as "NOT" SSA_NAME, and therefore cannot
> > satisfy the first if condition anyway.
> >
> > So here is my question:
> >
> > 1. How come variables like _4 and _108 are NOT ssa forms?
> > 2. then, what would be the proper way of identifying pointer
> dereferences,
> > something like *_4 = 0; and _109 = *_108 + 1?
> >
> > Best,
> > Shuai
>
