Make intrinsics available in function scope

[DanielKristofKiss]

Addresses PR #200.

As for any pull request, please make sure to go through the below
checklist.

Checklist: (mark with X those which apply)

• If an issue reporting the bug exists, I have mentioned it in the
  PR (do not bother creating the issue if all you want to do is
  fixing the bug yourself).
• I have added/updated the SPDX-FileCopyrightText lines on top
  of any file I have edited. Format is SPDX-FileCopyrightText: Copyright {year} {entity or name} <{contact informations}>
  (Please update existing copyright lines if applicable. You can
  specify year ranges with hyphen , as in 2017-2019, and use
  commas to separate gaps, as in 2018-2020, 2022).
• I have updated the Copyright section of the sources of the
  specification I have edited (this will show up in the text
  rendered in the PDF and other output format supported). The
  format is the same described in the previous item.
• I have run the CI scripts (if applicable, as they might be
  tricky to set up on non-*nix machines). The sequence can be
  found in the contribution
  guidelines. Don't
  worry if you cannot run these scripts on your machine, your
  patch will be automatically checked in the Actions of the pull
  request.
• I have added an item that describes the changes I have
  introduced in this PR in the section Changes for next
  release of the section Change Control/Document history
  of the document. Create Changes for next release if it does
  not exist. Notice that changes that are not modifying the
  content and rendering of the specifications (both HTML and PDF)
  do not need to be listed.
• When modifying content and/or its rendering, I have checked the
  correctness of the result in the PDF output (please refer to the
  instructions on how to build the PDFs
  locally).
• The variable draftversion is set to true in the YAML header
  of the sources of the specifications I have modified.
• Please DO NOT add my GitHub profile to the list of contributors
  in the README page of the project.

[DanielKristofKiss]

GCC today already works like this PR.
LLVM I'm going to publish a patch.

https://godbolt.org/z/37rqdr6ns

[rsandifo-arm]

I'm not sure about this kind of change. The statement “feature macro X indicates that Y is available” is still true. I think the difference is that feature macros are no longer the only indication of whether Y is available.

Also, #pragma GCC target changes the feature macros (although this doesn't work well when preprocessing the source as a separate step).

I suppose this is mostly aimed at functions with the target_version attribute. Should we require that, if an implementation supports target_version, and if it recognises a given feature F for the target_version string, it must:

• provide any ACLE header files associated with F
• make the intrinsics for feature F available in a target_version function that enables feature F, if the associated header files have been included.

(Not suggested wording)

Perhaps it would help to add a mapping from target_version feature names to feature macros.

[DanielKristofKiss]

I'm not sure about this kind of change. The statement “feature macro X indicates that Y is available” is still true. I think the difference is that feature macros are no longer the only indication of whether Y is available.

Correct, I'm happy drop these changes from the PR. The Intrinsics section could be extended further.

Also, #pragma GCC target changes the feature macros (although this doesn't work well when preprocessing the source as a separate step).

I suppose this is mostly aimed at functions with the target_version attribute. Should we require that, if an implementation supports target_version, and if it recognises a given feature F for the target_version string, it must:

provide any ACLE header files associated with F
make the intrinsics for feature F available in a target_version function that enables feature F, if the associated header files have been included.
(Not suggested wording)

I'll add something like this to the Intrinsics section.

Perhaps it would help to add a mapping from target_version feature names to feature macros.

unfortunately right now the feature names in the compilers are not standardised and different.
I'll do a separate PR for this.

[vhscampos]

Hi,

Issue #200 states that we should make all intrinsics available regardless of whether particular feature macros are defined or not.

On the other hand, my understanding is that this PR here maintains the way it is now. But it adds that intrinsics might be made available by the use of 'target' function attribute in spite of the corresponding feature macro not being defined.

What is the reason not to go all the way as the original issue proposes? If we did, intrinsics would be available at function scope by the simple virtue of unconditioned availability, with no differentiation between functions with or without the function attribute.

Thanks and sorry if I am missing something obvious.

[DanielKristofKiss]

Issue #200 states that we should make all intrinsics available regardless of whether particular feature macros are defined or not.

This is how today GCC and LLVM work.

On the other hand, my understanding is that this PR here maintains the way it is now. But it adds that intrinsics might be made available by the use of 'target' function attribute in spite of the corresponding feature macro not being defined.

What is the reason not to go all the way as the original issue proposes? If we did, intrinsics would be available at function scope by the simple virtue of unconditioned availability, with no differentiation between functions with or without the function attribute.

Thanks and sorry if I am missing something obvious.
The first iteration of the MR did that but probably looked as too intrusive also maybe not the best wording.

Would be nicer to tightly control the availability of the intrinsics but practically not worth the effort/complexity.

I'd be happy with the original, but maybe I'm biased.

[rsandifo-arm]

Issue #200 states that we should make all intrinsics available regardless of whether particular feature macros are defined or not.

This is how today GCC and LLVM work.

Perhaps we need to agree on a common meaning of “available”. I suspect we're saying the same thing in terms of how things work, but using different words to describe it.

In GCC it works like this:

• Including a header file defines all intrinsics associated with that header file (that the compiler knows about), regardless of the current target options. It has to work this way for intrinsics that are implemented as functions rather than macros, since it isn't semantically possible for functions to disappear and then reappear in C/C++.

• Even though (say) SVE2 intrinsics are defined whenever arm_sve.h is included, they can only be used in functions that have access to SVE2.

• Unless preprocessing is done as a separate step, __ARM_FEATURE_SVE2 (say) is automatically defined or undefined based on the current target options, as controlled by target pragmas. (But they do not change based on target attributes, which the programmer controls locally.) Here's a godbolt example: https://godbolt.org/z/h1YeTxfjY

Is that the functionality that we want? Or, instead of the final bullet point, do we want __ARM_FEATURE_SVE2 to have a fixed definition throughout the translation unit?