From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 607CC3856266; Thu, 14 Jul 2022 13:29:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 607CC3856266 Received: by mail-ej1-x634.google.com with SMTP id ez10so3376688ejc.13; Thu, 14 Jul 2022 06:29:23 -0700 (PDT) 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=2p1eGqJTcbbCWaR8icG90w7sFZQq3rEtneN+FPMQxKg=; b=DrBWmyYiCqFHHwu6OQUIk4yfc7F1jWb0CJ2JPRwRFBh+vD0JLaW1XViMnZ5faTaNva Z16rXi8IKIfKU5LXoIBj5GoJyRZ1v6K1UbW2OYRP4Aw2PMdoEQASrG0uVKM/tXREnRKe JU6+Myol4z6YWLAy3Y8s4WWFDwu4pkmB0mFlRhI4vUk9z611FUt3UhqkuUmJ3WiTJbIP /IFSt+7e/wpRcCt6h/ENA9ZPbqDAe1ITf7yyXY3TmZ8Kl6fpJRm6vj/3nIsuutYEqNYw zpDiDrKDiMVV20k1Yod830lmVPJKaTE/Sjklia3wNfSLx+cxEbun7EJ4SDhDm3Bz9C30 ZCqg== X-Gm-Message-State: AJIora+27qjQdzZ31U4dKBRt93HcBHfyfNP9zurTbMz9VgSOp5ssdjfb slN3izQ2VCjGnMJk3MEt3ULH5CRWvfIFdmJTr9EtWgoQ X-Google-Smtp-Source: AGRyM1tR+RafuPIWskn/1TPNexI7Uqy7Vmbb6lU+nyLU+n26Ylw52LKJpPtcIDyEbGqqp86XjZBAXo2CKpyw+10Jk8o= X-Received: by 2002:a17:906:4fcb:b0:716:ddcd:d124 with SMTP id i11-20020a1709064fcb00b00716ddcdd124mr8865120ejw.488.1657805360373; Thu, 14 Jul 2022 06:29:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 14 Jul 2022 15:29:08 +0200 Message-ID: Subject: Re: Creating a wrapper around a function at compile time To: Erick Ochoa Cc: GCC Development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Thu, 14 Jul 2022 13:29:25 -0000 On Thu, Jul 14, 2022 at 3:27 PM Richard Biener wrote: > > On Thu, Jul 14, 2022 at 2:35 PM Erick Ochoa via Gcc wrote: > > > > Hello, > > > > I'm looking for some help in how to create a new function at compile time / > > link time. The idea is an alternative form of constant propagation. > > > > The current implementation of ipa-cp, may specialize functions for which > > arguments may be known at compile time. Call graph edges from the caller to > > the new specialized functions will replace the old call graph edges from > > the caller to the original functions. Call graph edges which have no known > > compile time constants will still point to the original unspecialized > > function. > > > > I would like to explore a different approach to function specialization. > > Instead of only specializing functions which are guaranteed to have a > > compile time constant, I would like to also attempt to specialize the edges > > which do not have compile time constants with a parameter test. In other > > words, for call graph edges with non-constant arguments at compile time, > > create a wrapper function around the original function and do a switch > > statement around parameters. > > > > For example, let's say we have a function mul, which multiplies two > > integers. > > > > int > > mul (int a, int b) { > > return a * b; > > } > > > > Function mul is called from three different callsites in the whole program: > > > > A: mul (a, 2); > > B: mul (b, 4); > > C: mul (c, d); > > > > At the moment, ipa-cp might specialize mul into 3 different versions: > > > > // unoptimized original mul > > int > > mul (int a, int b) { > > return a * b; > > } > > > > // optimized for b = 2; > > int > > mul.constprop1 (int a) { > > // DEBUG b => 2 > > return a << 1; > > } > > > > // optimized for b = 4; > > int > > mul.constprop2 (int a) { > > // DEBUG b => 4 > > return a << 2; > > } > > > > and change the callsites to: > > > > A: mul.constprop1 (a); > > B: mul.constprop2 (b); > > C: mul (c, d); > > > > I would like instead to do the following: > > > > Create a function mul_test_param > > > > int > > mul_test_param (int a, int b) { > > switch (b) > > { > > case 2: > > return mul.constprop1 (a); > > break; > > case 4: > > return mul.constprop2 (a); > > break; > > default: > > return mul (a, b); > > break; > > } > > } > > > > The function mul_test_param will test each parameter and then call the > > specialized function. The callsites can either be changed to: > > > > A: mul.constprop1 (a); > > B: mul.constprop2 (b); > > C: mul_test_param (c, d); > > > > or > > > > A: mul_test_param (a, 2); > > B: mul_test_param (b, 4); > > C: mul_test_param (c, d); > > > > The idea is that there exist some class of functions for which the > > parameter test and the specialized version is less expensive than the > > original function version. And if, at runtime, d might be a quasi-constant > > with a good likelihood of being either 2 or 4, then it makes sense to have > > this parameter test. > > > > This is very similar to function tests for making direct to indirect > > functions and to what could be done in value profiling. > > > > I already know how to achieve most of this, but I have never created a > > function from scratch. That is the bit that is challenging to me at the > > moment. Any help is appreciated. > > So instead of wrapping the function why not transform the original function > to have a prologue doing a runtime check for the compile-time specialized > versions and perform tail-calls to them? > > What I'm missing is who would call mul_test_param in your case? Following your variant more closely would be doing value profiling of function parameters and then "speculative IPA-CP". Richard. > > > > Thanks! > > > > -Erick