Extend microarchitectures.json: Add cflags/cxxflags/fflags.

[t-karatsu]

@tgamblin
Fujitsu compiler has different optimization flags for each languages, so I add schema for flags for each languages.

[tgamblin]

@alalazo @boegel: see if you agree with this. I suggested this to the Fujitsu folks, as the fujitau compilers need different flags for the C/C++, and Fortran compilers. This is an extension of the existing schema; the idea is that if flags is present, that is the default, but cflags, etc. would be used preferentially if present.

[boegel]

I'm OK with this, but can you clarify the flags vs cflags? If both are present, what should happen? Only use cflags, or use the combination of both flags and cflags?

It seems to be the latter (otherwise flags is useless in the thunderx2 entry, but your comment suggests the former?

[tgamblin]

Only use cflags

This one.

Better way to put it: for each flag in cflags, cxxflags, and fflags, use that flag for the corresponding compiler if it is present, and if it is not present, use the value of flags for that compiler.

[boegel]

@tgamblin OK, but then why are the flags entries there for thunderx2? They're useless since cflags & co are also there?

[tgamblin]

@boegel: good question. I think @t-karatsu might've interpreted this as "use the combination of both flags and cflags" instead of what I was thinking.

Which one do you like better? I think it's less confusing to prefer the value of cflags over the value of flags rather than combining them. I was imagining that the tx2 entry would look like this:

        "fj": [
          {
            "version": ":4.0.0",
            "flags": "-Knolargepage -Nclang",
            "fflags": "-Knolargepage -KGENERIC_CPU -KNOSVE"
          },
          {
            "version": "4.1.0:",
            "flags": "-Knolargepage -Nclang -mcpu=thunderx2t99",,
            "fflags": "-Knolargepage -KGENERIC_CPU -KNOSVE"
          }

[boegel]

@tgamblin With an entry like that it's clear of course, but if both flags & cflags are present (which avoids the duplication in your last example), I would definitely assume it combines both (or throws an error if flags will never be used).

[alalazo]

@tgamblin From Spack's perspective this would be completely fine since in our current model Fortran, C and C++ are somehow treated in a special way and they map to cflags, fflags, etc.

From the perspective of a generic library (and in view of future enhancements to the compiler model in Spack) I wonder if the structure should be more explicitly calling out the languages for which the flags are for. For instance:

          {
            "version": "4.1.0:",
            "flags": {
                "default": "-Knolargepage -Nclang -mcpu=thunderx2t99",
                "fortran": "-Knolargepage -KGENERIC_CPU -KNOSVE"
            }
          }

so that we could easily extend it to other compiled languages like D or similar.

This also poses a question on the API of the Python library:

https://github.com/archspec/archspec/blob/6fbf84f01137584f47f817457cd3187bf67eb8ef/archspec/cpu/microarchitecture.py#L202-L214

Currently optimization_flags doesn't take any language as argument and returns a string with the flags. I see a couple of options here:

1. Still return a string with flags, add an optional language argument and if nothing is specified return the default flags. Require default to be present if flags is an object in the JSON file. (That would be my preference)
2. Don't add new arguments and return a dictionary with all the known flags.

Do you know of any other compiler using different uarch flags depending on the language that is used? Because if we are quite confident there is none we can also try to figure out if it is feasible to give different names to the two Fujitsu compilers.

[t-karatsu]

@tgamblin @alalazo @boegel
Thanks for comment to this.
As Todd said, I assumed to combine flags with each language flags. But if we want flags of one language, it is confusing that use two types of flags and combine them.
If it is possible to specify 'blank' in flags, it can also be described as follows.
As suggested by alalazo, I made each property name to language name.
How about this?

thunderx2
        "fj": [
          {
            "version": ":4.0.0",
            "default": "-Knolargepage -Nclang",
            "fortran": "-Knolargepage -KGENERIC_CPU -KNOSVE"
          },
          {
            "version": "4.1.0:",
            "default": "-Knolargepage -Nclang -mcpu=thunderx2t99",
            "fortran": "-Knolargepage -KGENERIC_CPU -KNOSVE"
          }
        ]
a64fx
        "fj": {
          "version": ":",
          "default": "-Nclang",
          "fortran": ""
        }

[alalazo]

Hi @t-karatsu ! A couple of comments:

1. I still think we have no answer to this part of my comment:

Currently optimization_flags doesn't take any language as argument and returns a string with the flags. I see a couple of options[ ... ] feasible to give different names to the two Fujitsu compilers.

2. I would keep the various flags under the flags attribute as all the other attributes are currently used for interpolation within the flags string (flags is currently a format string that gets interpolated i.e. f = flags.format(**kwargs), see other compilers for examples of that).

[t-karatsu]

@alalazo
Sorry for the slow response. I talked about this with our team.

Do you know of any other compiler using different uarch flags depending on the language that is used?

We don't know any compiler that needs different flags for each language, except Fujitsu compiler.
However, considering that gcc and clang are used in combination with another compiler,
I think there is room for consideration about optimization_flags.
(ex. gcc C/C++ compiler and nag fortran, clang C/C++ compiler and gfortran ...)

This is just one idea...

1. Still return a string with flags, add an optional language argument and if nothing is specified return the default flags. Require default to be present if flags is an object in the JSON file. (That would be my preference)

In a way close to '1.', How about choosing the compiler to use for each language?
And as you suggested,

we can also try to figure out if it is feasible to give different names to the two Fujitsu compilers.

In conjunction with this idea, we may be able to extract the necessary flags with the Fujitsu compiler.

ex. Fujitsu compiler in thunderx2
        "fj-c": [
          {
            "version": ":4.0.0",
            "flags": "-Knolargepage -Nclang"
          },
          {
            "version": "4.1.0:",
            "flags": "-Knolargepage -Nclang -mcpu=thunderx2t99"
          },
        ],
        "fj-fortran": {
          "version": ":",
          "flags": "-Knolargepage -KGENERIC_CPU -KNOSVE"
        }

And extract 'flags' by specifying compiler...
new_optimization_flags(fj-c, [version], c)
new_optimization_flags(fj-c, [version], cxx)
new_optimization_flags(fj-fortran, [version], fortran)