Date: Tue, 8 Nov 2022 11:00:13 +0100
Timur,
on Mon, 7 Nov 2022 07:50:28 -1000 you (Timur Doumler <cpp_at_[hidden]>)
wrote:
> Thanks for the info!
>
> I would be happy to help with a WG21 proposal to bring these features
> to C++. They seem very useful.
Thanks for volunteering !
With my limited knowledge of today's C++, I suspect that this would
indeed be a good addition to C++.
There are at least two major issues, though, that will make
transposing these definitions to C++ challenging: aliasing analysis
and library state.
(1) Aliasing of any state during the execution of such annotated
functions would easily invalidate any attempt to move calls around.
(2) There should be no or limited interaction between such functions
and C++ library functions.
(1) For aliasing analysis, to my knowledge, C++ currently doesn't even
have the terminology to express the necessary properties of these
attributes. In particular, C++ does not have `restrict` and more
importantly its underlying "based on" relation between pointers and
lvalues. 6.7.12.7 p10 Note 1 states a necessary property of functions
that have these attributes and pointer parameters:
If a function is known to be independent or effectless, adding
`restrict` qualifications to the declarations of all pointer
parameters does not change the semantics of any call.
All of this could evidently be avoided if pointer and reference
parameters would not be allowed for such attributed functions. But the
gcc attributes that are the base of all of this already allow them, so
it would be important to pin down the expected semantics.
(2) For the library, I looked through the whole C library to find
possible candidates that might need special treatment. I guess that
having a similar overview over the C++ library would need super-hero
capabilities.
Thanks
Jₑₙₛ
on Mon, 7 Nov 2022 07:50:28 -1000 you (Timur Doumler <cpp_at_[hidden]>)
wrote:
> Thanks for the info!
>
> I would be happy to help with a WG21 proposal to bring these features
> to C++. They seem very useful.
Thanks for volunteering !
With my limited knowledge of today's C++, I suspect that this would
indeed be a good addition to C++.
There are at least two major issues, though, that will make
transposing these definitions to C++ challenging: aliasing analysis
and library state.
(1) Aliasing of any state during the execution of such annotated
functions would easily invalidate any attempt to move calls around.
(2) There should be no or limited interaction between such functions
and C++ library functions.
(1) For aliasing analysis, to my knowledge, C++ currently doesn't even
have the terminology to express the necessary properties of these
attributes. In particular, C++ does not have `restrict` and more
importantly its underlying "based on" relation between pointers and
lvalues. 6.7.12.7 p10 Note 1 states a necessary property of functions
that have these attributes and pointer parameters:
If a function is known to be independent or effectless, adding
`restrict` qualifications to the declarations of all pointer
parameters does not change the semantics of any call.
All of this could evidently be avoided if pointer and reference
parameters would not be allowed for such attributed functions. But the
gcc attributes that are the base of all of this already allow them, so
it would be important to pin down the expected semantics.
(2) For the library, I looked through the whole C library to find
possible candidates that might need special treatment. I guess that
having a similar overview over the C++ library would need super-hero
capabilities.
Thanks
Jₑₙₛ
-- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Received on 2022-11-08 10:00:16