From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by sourceware.org (Postfix) with ESMTPS id D06173858C55 for ; Thu, 14 Jul 2022 13:42:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D06173858C55 Received: by mail-pg1-f177.google.com with SMTP id f11so1575471pgj.7 for ; Thu, 14 Jul 2022 06:42:14 -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=0pZlZo1ymK9EeF1ens+ILCv1iEQ0Aqhi4B1KeTYONCQ=; b=fIFv8MAd4R2yRKbZATwtGVc/jkV1FZSm89ox216Z4janRcPXAq50NGr9uNm98hLMzz vRLPphxrKiEoCITCTgxtflTqM/2gx/4nlIRHHmGV+4ZJLlen7jSoeOoTVJLWfb63RTbs fQQrnoSmrh3ISr0URNdzUYJO5fJpmIfH0iSGmVSim6ELREuO1b5gC5UH3exVFEPPKI7e ZaDU9yFtCIaACJap3lWhO9WxIrkvvjs4en6ON2Xa/7cyidRhj3bDiKlIpQaa8wGG7ZQ8 l0DxHH+AFuGhFN2Qt2oJUbNonESXAv4YbYax/1bF42umPE1mHJPKvMfrOodKNnxGlqWF AwAg== X-Gm-Message-State: AJIora+QW79HuhdsuBUSk887ZJNGSGrIZYAZ4cnMoKp/FuPYPTnHoNUt DT3Y6qE3VeNScNSZp+0UKEWDFK4AQkvFaA== X-Google-Smtp-Source: AGRyM1u34T8Cp8QZf3aMJOoqWNxoKpxjYLNvpnC8plgT7FtLVmejTL7NUDWsj47jbjxq5w+H7QD4Yw== X-Received: by 2002:a05:6a00:181c:b0:52a:bc83:d767 with SMTP id y28-20020a056a00181c00b0052abc83d767mr8316894pfa.76.1657806133760; Thu, 14 Jul 2022 06:42:13 -0700 (PDT) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com. [209.85.210.178]) by smtp.gmail.com with ESMTPSA id b3-20020a170902d50300b0016c50179b1esm1505319plg.152.2022.07.14.06.42.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Jul 2022 06:42:12 -0700 (PDT) Received: by mail-pf1-f178.google.com with SMTP id j3so1881346pfb.6 for ; Thu, 14 Jul 2022 06:42:12 -0700 (PDT) X-Received: by 2002:a65:6bc4:0:b0:3c2:2f7c:cc74 with SMTP id e4-20020a656bc4000000b003c22f7ccc74mr7613368pgw.307.1657806132009; Thu, 14 Jul 2022 06:42:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erick Ochoa Date: Thu, 14 Jul 2022 15:46:14 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Creating a wrapper around a function at compile time To: Richard Biener Cc: GCC Development X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:42:16 -0000 Hi Richard, > > > 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? > The idea is that all callsites to mul may call instead mul_test_param or only those for which there is no known compile time constant. If we had some more information about the distribution of the parameter values at runtime, then we could even choose not to use the wrapper. > Following your variant more closely would be doing value profiling > of function parameters and then "speculative IPA-CP". > Yes, the idea of doing value profiling on function parameters certainly fits this very well. I refrained from calling it "speculative IPA-CP" and instead called it specialization with a parameter test but the idea I think is the same. However, the main difference between "speculative IPA-CP" and this idea is that (if I understand correctly how speculative IPA-CP works) is that instead of changing the callsite C to the following version: C: mul_test_param (c, d); speculative IPA-CP will have the transformation C: if (a == 2) mul.constprop1 (a) else if (a == 4) mul.constprop2 (a) else mul (a, b) Which depending on how many non compile-time constant callsites there are, will increase the size of the binary. That's why I prefer the wrapper around the function. But this would be essentially inlining the wrapper. As of now, the only "speculative IPA-CP" that I've seen is the speculation on the target of the indirect edge. I could look into exactly how this mechanism works to try to instead speculate on an arbitrary argument. Do you think that would be a good first step instead of creating a wrapper and replacing the edges to the wrapper?