From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id DE45738A8155 for ; Sun, 30 Oct 2022 07:48:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DE45738A8155 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-ed1-x536.google.com with SMTP id a67so13449080edf.12 for ; Sun, 30 Oct 2022 00:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=PFvEE6L370QXopoNtXkLCpxwnRMdsFe7c5agc2OGr5c=; b=GWAeELnpfaG69s7lvepJCrR8dWb6eQC5KE45qSFAMVxcw2xX/Fg4yA+MgoroHoFokL ozH6aSt70bLnDZLFVdgI2iR/cuFKWmLqLf+J8bjB+jnsbv6sJNyyf0106xQnThjUiohN kK5nqeuXd9qwnF23l0X/gVbge+tEMMjIfc9IBLFAybiFGUpVl0KzBWYd6rJ+90bJHmu/ mcuC77Kld+v6FaI7PwPP5llrUruUYC7/7NaIG9YS42PjSnJn6jaLElihHKF5iQ0bhVm3 KGP/VdnnTHPp51Z5j0ZGscFBg6yB8fslrifD7iD+TmQvSShMfpMpB17od8Pm5DV7iLf+ 93Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PFvEE6L370QXopoNtXkLCpxwnRMdsFe7c5agc2OGr5c=; b=XkbMQv57aTasIpu4d5s8eDyGgNyMRB4sHh6QBLhkJVxNc4i43EkXLtlPdA2D7jf+Hc vT+DA0H2/PZd5ft8Gv/OvmdLFkTrl8i4hp7LnlkNbqixfFI61shY3Kxmq0gHdw9pKp+g lICHEjcKoLKzgrlll5Oc1+AyuluWr2YDAzi264iySoTJW0X95SjQxgHjzt/jb4I7Lr7/ y22+rISL2uL2wCZGYSf0VrZrDT7FOuF6YLolvrzgjoNsUdUhi4tjb9mx1V8UhKiI40LT 6UQrueG/G6ZKTb7Yzyl7vidO4Ex+GUq9GfFxUwVAi1Vk6NSjbYSYVEk5/y2WrMAeNAf+ VOTA== X-Gm-Message-State: ACrzQf1AqH9W7vPb2A6DuLdqfSR+ClNwRT9W2MXoOk1MTtX0hwqQOsh7 sCtKeN91CB2mfpef9g8pF+o= X-Google-Smtp-Source: AMsMyM7Dp1fDBM6GQfimYg9NubopdVGQ3eGjeRizDEIZFnWPU8GP/5tVYo71Xe0+qoKNXgCuxpLZ8g== X-Received: by 2002:a05:6402:14ca:b0:462:e375:a1f4 with SMTP id f10-20020a05640214ca00b00462e375a1f4mr7862901edx.344.1667116123554; Sun, 30 Oct 2022 00:48:43 -0700 (PDT) Received: from nbbrfq ([2001:871:227:81c4:d7ff:3a0e:48da:5fe3]) by smtp.gmail.com with ESMTPSA id ku11-20020a170907788b00b0078ba492db81sm1590453ejc.9.2022.10.30.00.48.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Oct 2022 00:48:43 -0700 (PDT) Date: Sun, 30 Oct 2022 08:48:39 +0100 From: Bernhard Reutner-Fischer To: Dave Love via Fortran Cc: rep.dot.nop@gmail.com, Dave Love Subject: Re: adding attributes Message-ID: <20221030084839.118ef0c8@nbbrfq> In-Reply-To: <87pmecdni6.fsf@manchester.ac.uk> References: <87pmecdni6.fsf@manchester.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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 Fri, 28 Oct 2022 15:35:45 +0100 Dave Love via Fortran wrote: > Assuming there's no technical reason not to, can someone say what would > be involved in adding relevant attributes (at least function ones) like > those for C? I'm thinking particularly of target_clones, but others > probably make sense. Well we already have !GCC$ ATTRIBUTES attribute-list :: var-name [, var-name] ... See https://gcc.gnu.org/onlinedocs/gfortran/ATTRIBUTES-directive.html > > I don't know my way around, but I had a quick look, and it at least > wouldn't be as straightforward as I hoped. See gcc/fortran/decl.cc gfc_match_gcc_* For example the CDECL attribute probably comes close to target_clones: subroutine mysub1() !GCC$ ATTRIBUTES CDECL :: mysub1 ! body of mysub1 here For target_clones you would most likely need a slightly different parser for you need the user to specify the actual target_clones somehow. You would probably make a suggestion and discuss the proposal here. Ideally the syntax would be the same as in C. Finally you would have to lower the target_clones, not sure offhand who creates the ifunc dispatcher, the frontend or the middle-end. There is expand_target_clones in gcc/multiple_target.cc that probably comes into play. So yes, that seems to create the ifuncs if i read that correctly. Hence the implementation in the frontend should not be all too complicated, it seems. To your initial remark about a technical reason not to support it i would point you to what Tobias said to me some time ago and which i certainly told other people more than once, too: https://patchwork.ozlabs.org/comment/958570/ ---8<--- In general, I prefer to stick to standard methods (which are portable) and think that those user knobs often make things slower than faster (as they tend to stay for years, even after the hard- ware as moved on - or they are even inserted blindly). ---8<--- In former times, you would compile your library multiple times and provide a distinct, optimized version for each of the CPUs. Maybe that would work for you equally well, without target_clones? HTH