Re: adding attributes

[Dave Love <dave.love@manchester.ac.uk>]

Bernhard Reutner-Fischer via Fortran <fortran@gcc.gnu.org> 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!