From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 881163858CDA for ; Mon, 25 Sep 2023 17:27:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 881163858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3231d6504e1so3307540f8f.2 for ; Mon, 25 Sep 2023 10:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695662825; x=1696267625; darn=gcc.gnu.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oYZBokS8NpY/1rhj10TfpEKCu6Z2xCQ1QZh8JECk6RE=; b=WDNRr5pw4JEG0b+vEgRsGDRtBdiZO6Xr/LcA2v7a1uqtVA6JdHoIF8ccL13WGuDZr7 a+n7TEdQMVUTPAWZ6wD5pevadESbXTfUwORVWGyF9qGioEMuT9SzpDO05LFvnvYcQwfH 0OKCoQvgr4eFPF0NzBcD63zmT/hif6cwYtu9r5nY4uMT6E6OvgFHfc4k4lR5Y4qkznTb 6FbmQFde7AJUBLf+N5XO94TopeyQI1sluPzVeVeovxnQwFIuzcmIWbgMt291S2c5DI3x RAKbfbHWutKYMiyct1iqJmZGWUNa0e+Np+ZxCp6CbFokXpUz24O86O/9gR1B3qiHiE0n IFgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695662825; x=1696267625; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oYZBokS8NpY/1rhj10TfpEKCu6Z2xCQ1QZh8JECk6RE=; b=A0+U1J6/lQhTEpbiEBwctUeCcC+kOv3aAQ5qEWM+cmMH955CSJgzGe/3g9ouktXwZb +wsnGXS7d5ZUKPZp3Ts87iqsknnv1Xf4wh4qt7OIl/HLIb7YfqZ7zE52Y7mSRuMrqbL8 UN2pFz8hok/U7RQcI2TnIJRDnhb9SOsa+GGzZJ46JQpYbgVffbiF2A+zZaplM6izHcaA CF/dNi3t4K6cmbe2nh7j1LubURconjKhUZArlSBnT7DUysNmOzNlIn8Dcl3vPYpqaJuh mkUnoj4zIXXvNPlcYCGjeYUDW6EFoHsFML+FByXY0mLwSUJ5siKZ+cKxiox2mZWxvbpj LjLg== X-Gm-Message-State: AOJu0YyYFUhvJ0M1TkjtTXyS8gzjdLQX0aGJA+8yBJcFGKnfZmA4LOXc 9iG1UVRbvFqJKj9Ml0+NMgTrVHPOp58YqPzAL/w= X-Google-Smtp-Source: AGHT+IH3k7ORcjyjNVqGgxgte+v1pQGoNDhpRaSh1KGtdSBu7617W3D2JTiq2ijx1tIfXgAuxB7bpNz6LbYmWkIwSBc= X-Received: by 2002:a05:6000:1c7:b0:31f:f99c:6013 with SMTP id t7-20020a05600001c700b0031ff99c6013mr7033808wrx.61.1695662824853; Mon, 25 Sep 2023 10:27:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Pinski Date: Mon, 25 Sep 2023 10:26:51 -0700 Message-ID: Subject: Re: ipa-inline & what TARGET_CAN_INLINE_P can assume To: Richard Sandiford , hubicka@ucw.cz, gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Sep 25, 2023 at 10:16=E2=80=AFAM Richard Sandiford via Gcc wrote: > > Hi, > > I have a couple of questions about what TARGET_CAN_INLINE_P is > alllowed to assume when called from ipa-inline. (Callers from the > front-end don't matter for the moment.) > > I'm working on an extension where a function F1 without attribute A > can't be inlined into a function F2 with attribute A. That part is > easy and standard. > > But it's expected that many functions won't have attribute A, > even if they could. So we'd like to detect automatically whether > F1's implementation is compatible with attribute A. This is something > we can do by scanning the gimple code. > > However, even if we detect that F1's code is compatible with attribute A, > we don't want to add attribute A to F1 itself because (a) it would change > F1's ABI and (b) it would restrict the optimisation of any non-inlined > copy of F1. So this is a test for inlining only. > > TARGET_CAN_INLINE_P (F2, F1) can check whether F1's current code > is compatible with attribute A. But: > > (a) Is it safe to assume (going forward) that F1 won't change before > it is inlined into F2? Specifically, is it safe to assume that > nothing will be inlined into F1 between the call to TARGET_CAN_INLINE= _P > and the inlining of F1 into F2? > > (b) For compile-time reasons, I'd like to cache the result in > machine_function. The cache would be a three-state: > > - not tested > - compatible with A > - incompatible with A > > The cache would be reset to "not tested" whenever TARGET_CAN_INLINE_P > is called with F1 as the *caller* rather than the callee. The idea > is to handle cases where something is inlined into F1 after F1 has > been inlined into F2. (This would include calls from the main > inlining pass, after the early pass has finished.) > > Is resetting the cache in this way sufficient? Or should we have a > new interface for this? > > Sorry for the long question :) I have something that seems to work, > but I'm not sure whether it's misusing the interface. The rs6000 backend has a similar issue and defined the following target hooks which seems exactly what you need in this case TARGET_NEED_IPA_FN_TARGET_INFO TARGET_UPDATE_IPA_FN_TARGET_INFO And then use that information in can_inline_p target hook to mask off the ISA bits: unsigned int info =3D ipa_fn_summaries->get (callee_node)->target_inf= o; if ((info & RS6000_FN_TARGET_INFO_HTM) =3D=3D 0) { callee_isa &=3D ~OPTION_MASK_HTM; explicit_isa &=3D ~OPTION_MASK_HTM; } Thanks, Andrew Pinski > > Thanks, > Richard