From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 3C2EB3858D3C for ; Mon, 17 Jan 2022 19:18:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3C2EB3858D3C Received: by mail-wm1-x32d.google.com with SMTP id g81-20020a1c9d54000000b0034cd1acd9b5so218026wme.1 for ; Mon, 17 Jan 2022 11:18:23 -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=sVXi8iGwvtcH45OAgix0twvRvru5XoULHrffEj/ms1o=; b=xqZPmHPSMjpC7Y72e66MTSzwVf9BS3zX9qd8fRwTqSAlH2YP7uDpvM/zMiYjnZ6nxG YDbs7zIhC+iADtFpQp4nIS9TKXFeYydG4sOyk5ZjupwLr15eTl2jusNJGlB2x7FFycqs ovr+rQJIs9+M9CcG5MOXb1HMhml1i3jNz8bIerRh7CzWWwSrtJfSokWmewabCwYO2sEH 9EsaRT90Nl01h1jh7m564gnspmZAF5/SPFYSqobfvx3f7vGp05nJ5+yPGIQmA3rwmgQG M9gLexBV0QxKNSjqatVK4IOLYgpiNb7G9Z2wLDvajjESDv9CKrk91AbIHMCFSIgG9yOW hkFQ== X-Gm-Message-State: AOAM531tZ2eZ2I/S5UwSJQ0fcEKq6psx2HbmYNZ+zVO8tSes2kFW1mes sj8kpQIleStBXlwtJ9AkJqjjspY78zH7D7aiWNU= X-Google-Smtp-Source: ABdhPJwBmXUeLawFEeMU/p0YR8T/xE1GEIQYyQsAlDbMzl78sdwvU9V3RPhgrf5o/oquEl475opGuhW851opobm0EM8= X-Received: by 2002:a05:6000:154c:: with SMTP id 12mr5140222wry.380.1642447101869; Mon, 17 Jan 2022 11:18:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Shubham Narlawar Date: Tue, 18 Jan 2022 00:48:10 +0530 Message-ID: Subject: Re: Accessing const parameter of GIMPLE_CALL To: David Malcolm Cc: GCC Development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.3 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: Mon, 17 Jan 2022 19:18:26 -0000 On Mon, Jan 17, 2022 at 5:23 AM David Malcolm 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 (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 >