Re: Accessing const parameter of GIMPLE_CALL

[Shubham Narlawar <gsocshubham@gmail.com>]

On Mon, Jan 17, 2022 at 5:23 AM David Malcolm <dmalcolm@redhat.com> wrote:
>
> On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote:
> > Hello,
>
> Hi; various notes inline below...
>
> >
> > My aim is to iterate over gimple call stmt parameters and check
> > whether it is constant or constant expression and mark/store them for
> > some gimple transformation.
> >
> > I have an intrinsic function call of the following -
> >
> > __builtin_xyz(void*, 7, addr + 10);
> >
> > I want to find its parameters which are either constant or constant
> > expression i.e. 7 and addr + 10 from above case.
>
> Gimple "flattens" all tree-like operations into a sequence of simple
> operations, so I would expect the gimple for this to look something
> like this:
>
>    _tmp = addr + 10;
>    __builtin_xyx (7, _tmp);

Hi David,

Yeah. Correct.

>
> Your email doesn't specify *when* your code runs.
>
> The IR for a function goes through several stages:
>
> - an initial gimple IR without a CFG
> - gimple with a CFG, but not in SSA
> - gimple-SSA with a CFG
>   (most of the gimple optimization passes operate in this form of the
> IR)
> - gimple with a CFG, but no longer in CFG form, immediately before
> conversion to RTL-with-CFG form
> - RTL-with-CFG
> - RTL-without a CFG
> - assembler
>
> Are you doing it as part of a plugin, or modifying an existing pass?
> In either case, it's a good idea to dump the gimple and see what the
> code has been turned into.  You'll probably find the following options
> useful:
>   -fdump-tree-all -fdump-gimple-all
>
> or alternatively just turn it on for the pass that you're working on.

I am doing it as a plugin and it is placed just after
"pass_build_cgraph_edges" i.e. Call Graph Construction.

>
> >
> > [1] I tried below macro but there is very less usage in the entire
> > source code -
> >
> > tree fn_ptr = gimple_call_fn (dyn_cast<gcall *> (stmt));        //stmt
>
> gimple_call_fn returns the function that will be called, a pointer.
> This is very general, for handling things like jumps through function
> pointers, but here you have the common case of a callsite that calls a
> specific function, so "fn_ptr" here is:
>    &__builtin_xyx
> i.e. an ADDR_EXPR where operand 0 is the FUNCTION_DECL for the builtin.

Got it.

>
> > = gimple_call
> > function_args_iterator iter;
> > tree argtype;
> >
> > if (TREE_CODE (fn_ptr) == ADDR_EXPR)
> > {
> >   FOREACH_FUNCTION_ARGS (fn_ptr, argtype, iter)
>
> Looking in tree.h, FOREACH_FUNCTION_ARGS takes a FUNCTION_TYPE as its
> first argument, but the code above is passing it the ADDR_EXPR wrapping
> the FUNCTION_DECL.

Understood.

>
> Unfortunately, because these things are all of type "tree", this kind
> of type mismatch doesn't get caught - unless you build gcc from source
> (with --enable-checking=debug) in which case all these accesses are
> checked at the compiler's run time (which is probably a good thing to
> do if you're hoping to work on gcc for GSoC).

I am working on gcc version 10.2.0 and there is no such flag as
"--enable-checking" but there is "--enable-gcc-checking".

>
> You can get the FUNCTION_TYPE of a FUNCTION_DECL via TREE_TYPE
> (fndecl), or alternatively, gimple_call_fntype (call) will get the type
> of the function expected at the call stmt (useful if there was a type
> mismatch).
>
> That said, FOREACH_FUNCTION_ARGS iterates through the types of the
> params of the FUNCTION_TYPE, but it sounds like you want to be
> iterating through the arguments at this particular *callsite*.
>
> For that you can use
>   gimple_call_num_args (call);
> and
>   gimple_call_arg (call, idx);

Yes. This is exactly what I was looking for!

>
> >     {
> >         if (TREE_CONSTANT (argtype))
> >            // Found a constant expression parameter
> >     }
> > }
> >
> > The problem is I am getting only one parameter tree but there are 2
> > constants in the above function call. Even if "addr + 10" is treated
> > differently, I want to mark it for the transformation.
>
> I think you're seeing the function pointer being called, ather than the
> params.

Yes.

>
> >
> > a. Is the above correct method to iterate over function call
> > parameters?
>
> As noted above, it depends on whether you want to iterate over the
> types of the parameters in the function's decl, or over the expressions
> of the arguments at the callsite.  I believe the above explains how to
> do each of these.

Yes. Above clears all my queries and thanks for detailed explanation.
It has helped a lot!

>
> > b. Is there a different way to achieve the above goal?
>
> If you're looking to get familiar with GCC's insides, I recommend
> stepping through it in the debugger, rather than relying on injecting
> print statements and recompiling, since the former makes it much easier
> to spot mistakes like the one above (which we all make).

Sure.

>
> I've written a guide to debugging GCC here:
>
> https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html

Thanks for sharing! It is helpful blog

Regards,
Shubham

>
>
> Hope this is helpful
> Dave
>