From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 7270A3858402 for ; Sun, 16 Jan 2022 23:53:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7270A3858402 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-615-tXvRK3AKPPKNEc1PdyFC3g-1; Sun, 16 Jan 2022 18:53:16 -0500 X-MC-Unique: tXvRK3AKPPKNEc1PdyFC3g-1 Received: by mail-qv1-f71.google.com with SMTP id jv3-20020a05621429e300b0041696de044bso13899239qvb.14 for ; Sun, 16 Jan 2022 15:53:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=2AciwUvdvsZgMsKjauWBF5lebs53EP8r8x30Dyp9av8=; b=rU0Wz55AOJfaukOdII4SyyCmkLjkulwK/kk2Zgee9S+ye0P3QsMY5h6Q4UR7iVZn2V Q4JudD9oYCBNQZZ0SO+nNmUsXx1lTZBH0TyXiOO5ODQ/ArqfE/LHIdO324CEcUVG0Qo7 FxbfDy0LEUfMghiPGAs1wRsqvFbAurYWqMImmFGZKcl/f6DLEuiBFZchqHdmBTzRNEnq AYKOX9NbJENXCIIRXPRUfzdlNYx3mlgwUGDS+N+zvBvClJ/6VOzVDrnrdchmliqcjAhn OkP28ZKZf/yXorZHZSN1pjhsjxzhgD88AFfqZE1/UPGL4M2Q5h2beoiOh2s3w/mAEBQe dxfg== X-Gm-Message-State: AOAM530ENCGfMnmTm2ExXQMoypnY200OtkdWS+lNOHsGui46sWu4kZDF DXzUAEzcSmFACxLOgqWwvY3JNggIPZxO3AKjg39SQKf74As5EwBj+6bxEkvIJOnei56aSkzXMrS mp3IY4f0= X-Received: by 2002:a05:622a:1822:: with SMTP id t34mr15068689qtc.436.1642377195515; Sun, 16 Jan 2022 15:53:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJxt2MzNjmvAFi9mMLQ5QMnqWXxn9K7+WW2xPXN9G9nun/e/wV0UhpwwqmApKSUhVmsxt843xQ== X-Received: by 2002:a05:622a:1822:: with SMTP id t34mr15068684qtc.436.1642377195230; Sun, 16 Jan 2022 15:53:15 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id d10sm3999210qtb.63.2022.01.16.15.53.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Jan 2022 15:53:14 -0800 (PST) Message-ID: Subject: Re: Accessing const parameter of GIMPLE_CALL From: David Malcolm To: Shubham Narlawar , GCC Development Date: Sun, 16 Jan 2022 18:53:13 -0500 In-Reply-To: References: User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: Sun, 16 Jan 2022 23:53:22 -0000 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. > > 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