From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id B56443858D38 for ; Mon, 7 Nov 2022 11:04:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B56443858D38 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=manchester.ac.uk Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1orzvT-0002TB-4s for fortran@gcc.gnu.org; Mon, 07 Nov 2022 12:04:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: fortran@gcc.gnu.org From: Dave Love Subject: Re: adding attributes Date: Mon, 07 Nov 2022 11:04:17 +0000 Message-ID: <87zgd381qm.fsf@manchester.ac.uk> References: <87pmecdni6.fsf@manchester.ac.uk> <20221030084839.118ef0c8@nbbrfq> <87edund73d.fsf@manchester.ac.uk> <20221103001926.725fd9bf@nbbrfq> Mime-Version: 1.0 Content-Type: text/plain User-Agent: secret agent Cancel-Lock: sha1:aOFGYtfOkZPs6cbfxz1APhTu+2Q= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Bernhard Reutner-Fischer via Fortran writes: > I see. > So target_clones is one thing. What other attributes would be important? At least optimization-related ones could be useful, and possibly others. I haven't made a list, but could do. > In your job script you would use cpuid(1) to determine a properly tuned > binary for the parts of the cluster you run on. Or the installed > binaries are tuned for the host they are installed on and are located in > a uniform place per application. > >> >> Multiple compilation isn't a good solution. I haven't followed the > > It might not be good, but it's cheap and easy if you only have a small > set of different arches and subarches each. In a controlled > environment, with a batch scheduler. Won't work in the wild of course. I know all that you can do, but my opinions are from extensive experience managing rather heterogeneous HPC clusters and working on dynamic dispatch in libraries. (The worst thing about gfortran for system management is the lack of backwards-compatibility in module formats and libgfortran.) > But since you cannot mix target_clones across arch-boundaries, > supporting those for a distro will probably be rather ugly anyway. Yes, you need simple pre-processing, as you do for the attributes in C, unless there was some extra guard facility added. > heh, me neither. Luckily yesterday was a holiday, so what i ended up > with was the following, fya. Gosh; I thought it would take a while even if you knew your way around. I didn't want to spoil a holiday! (I'd aim to do such things on work time.) > I've added a > /* Attributes set by compiler extensions (!GCC$ ATTRIBUTES). */ > unsigned ext_attr:EXT_ATTR_NUM; > + tree ext_attr_args; > > to struct symbol_attribute where i can prepare the tree_list for the > attrs right from the start. The lowering is then rather simple and > uniform, just chainon the prepared attributes and be done. If I understand correctly, I could go through and add ones that look useful (for debate). I have experience of using several in C (at least once even for g77 runtime). > target_clones does not require a bump in the module format, i'd say, > because the main entry point does not change. Will have to check if > the clones do not end up being emitted in the module, they shouldn't be. > Other attributes _may_ require a change in the module format though. > These would need checking on a per case basis. I don't understand the module format, but I wouldn't have expected relevant attributes to change interfaces. Anyway, thanks!