Understand pointer deferences in GIMPLE

Richard Biener richard.guenther@gmail.com
Tue Jul 14 09:38:00 GMT 2020


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


More information about the Gcc mailing list