From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id 37F3D385801E for ; Tue, 18 Jan 2022 18:50:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 37F3D385801E Received: by mail-wm1-x334.google.com with SMTP id l35-20020a05600c1d2300b0034d477271c1so422900wms.3 for ; Tue, 18 Jan 2022 10:50:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DGh8cVHJbC0F/PB8UHVD1AtANjaTbBgf2/H16kAJ5bg=; b=W2wPI1G5In9516mKZZN7jhhWK/5OhLkLsmVVr+inBEEZ/XkfjQPXkm50bGAqiPhYEm c9AySlEBCKZ3P7XJoV+oVpJGHGSAX+Q++Tis72RgkM54hGOqrR7Vg804XcbaSed8UY7+ C1e6laFK/2pPsrZn+dcOpIpHjFDXGyicCaTN3d+14WbiQlk7mVU8HI9mfqBiKb2xsxP8 bVIr9RmL7qmd+VjJBIFE4Gpj1ZkWZ+6SbYyFvb41lIvm43x2p7KV1hVwTA+rBin8duCX LddL9b4myzC/RtWbLuNrBANFSiBzTgwnZ3rLFRyrWFhKaTKEwlyTwGEr9Zq6rpLEoYbg iIyQ== X-Gm-Message-State: AOAM53348TPbM4C9H2H6ms1ZIxGh3iCDdMkuz+eNs2OtrIgSJZVR1vH1 JTP2hjLxxurz9Xntx5OB8LHtZCjtBS1OnJjeW+c= X-Google-Smtp-Source: ABdhPJzIrijT7uGVvn8PVEb+tZhxTFDbsshI5qc9U1qeDeiOPz7aDV39knLo1tHxgX/tEVB1DJDGC3fMZBA9QYqwYrw= X-Received: by 2002:a1c:a141:: with SMTP id k62mr26178013wme.172.1642531835009; Tue, 18 Jan 2022 10:50:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Shubham Narlawar Date: Wed, 19 Jan 2022 00:20:23 +0530 Message-ID: Subject: Re: Accessing const parameter of GIMPLE_CALL To: Richard Biener Cc: David Malcolm , GCC Development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2022 18:50:38 -0000 On Tue, Jan 18, 2022 at 2:20 PM Richard Biener wrote: > > On Mon, Jan 17, 2022 at 8:19 PM Shubham Narlawar wrote: > > > > On Mon, Jan 17, 2022 at 1:55 PM Richard Biener > > wrote: > > > > > > On Mon, Jan 17, 2022 at 12:54 AM David Malcolm via Gcc 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); > > > > > > > > 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. > > > > > > > > > > > > > > [1] I tried below macro but there is very less usage in the entire > > > > > source code - > > > > > > > > > > tree fn_ptr = gimple_call_fn (dyn_cast (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. > > > > > > > > > = 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. > > > > > > > > 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). > > > > > > > > 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); > > > > > > > > > { > > > > > 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. > > > > > > I think you are iterating over the functions formal argument types > > > rather than a specific call parameters. To look at the actual > > > parameters use sth like > > > > > > for (unsigned i = 0; i < gimple_call_num_args (stmt); ++i) > > > { > > > tree arg = gimple_call_arg (stmt, i); > > > if (CONSTANT_CLASS_P (arg)) > > > ... > > > } > > > > > > and replace CONSTANT_CLASS_P with is_gimple_ip_invariant () > > > if you also want to handle symbolic constants like &global_var > > > as constant. > > > > Understood. I was iterating on formal parameters. But the above solves > > the problem. CONSTANT_CLASS_P() and is_gimple_ip_invariant() are > > helpful on integer constant. > > > > In below gimple dump w.r.t code snippet shared by you from above - > > > > def_stmt _14 = (unsigned int) _13; > > __builtin_xyz(instrn_buffer.3_11, 12, _14); > > > > Here, all actual parameters are represented by tree whose classes are - > > > > instrn_buffer.3_11 - tcc_exceptional > > 12 - tcc_constant > > _14 - tcc_exceptional > > > > The 1st and 3rd parameters are denoted by tcc_exceptional which fits > > no category of tree, but I want to collect such 3rd parameter i.e. to > > identify it whether it is variable or expression. Is it possible to do > > it? > > You can check TREE_CODE (arg) == SSA_NAME and look at > the defining stmts via SSA_NAME_DEF_STMT. Note that prior to > the into SSA pass only temporaries created by the gimplification > process are SSA names and some SSA data structures like > immediate uses are not available. Thanks for the suggestion. This gets me what I wanted! With this my analysis pass is complete - "of finding potential constant expressions in builtin intrinsics". SSA_NAME_DEF_STMT gets me stmt representing a parameter which is either PARM_DECL or SSA_NAME. I think where immediate uses are not available, the tree is represented as PARM_DECL. Thanks everyone for the suggestions! Regards, Shubham > > > I want to mark _14 for gimple transformation if - > > a. it is a variable like above _14 representing a constant. > > b. it is a expression _14 + 7 i.e. again at gimple level, it is case (a) > > c. it is a phi node which represents constant when there is a case of > > ternary operator usage. > > > > How to identify such an actual parameter of gimple call? > > > > The aim of the above scenario is to identify such > > variables/expressions and then apply constant folding and propagation. > > If constant folding and propagation are not happening on actual > > parameters of intrinsic call, then I need to write some plugin to do > > it. My plugin is placed just after "pass_build_cgraph_edges" i.e. > > Callgraph Construction. > > > > Thanks for the helpful suggestions. > > > > Regards, > > Shubham > > > > > > > > > > Richard. > > > > > > > > > > > > > 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. > > > > > > > > > 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). > > > > > > > > I've written a guide to debugging GCC here: > > > > > > > > https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html > > > > > > > > > > > > Hope this is helpful > > > > Dave > > > >