Thanks for the good points you brought up.

The intention here is to help prove legality of compiler optimizations. I think we need to focus on common cases. Most important things in my opinion are the following (in the order of importance):

1- A definition of a “container” in a way that can provide guarantees about the underlying memory allocated for the container and who can access it. (To help with alias analysis)
2- Specifying basic operations such as add/remove/alloc/realloc/dealloc/size.
3- Possibly specifying the type of container could help as well (vector, priority queue, etc.). This can provide extra guarantees about the behavior of the code and we have optimizations that can take advantage of this.

You correctly mentioned: “the list of possibilities is endless”. I agree. The more specialized attributes, are less likely to appear in the code and less likely to be useful for the compiler. So we have to stop somewhere.

I hope this can address your concerns.



-----Original Message-----
From: Std-Proposals [mailto:std-proposals-bounces_at_lists.isocpp.org] On Behalf Of Frederick Virchanza Gotham via Std-Proposals
Sent: January 12, 2025 4:06 PM
To: std-proposals_at_lists.isocpp.org
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_gmail.com>
Subject: Re: [std-proposals] Providing information about data structures to the compiler

On Sat, Jan 11, 2025 at 11:18 PM Ehsan Amiri <ehsan.amiri_at_huawei.com> wrote:
>
> Yes, I have something like your example in mind.


How intelligent do you want the compiler to be? I mean if it encounters:

     void emplace_back(T const &) [[container_add, might_realloc]]
     {
         . . .
     }

then should it use the remote API to access ChatGPT to ask it what way the assembler should be written for a (stereotypical) method that adds to a container and might reallocate?

I'm just thinking here that you're expecting a lot from the compiler.
And that it will all be based on stereotypes (or at least based on most common practise).

Fair enough if you keep it to simple ideas, such as marking a method as "never allocates memory", "rarely allocates memory" or "frequently allocates memory", but the list of possibilities is endless -- I mean you could mark a method as adding an item to a sorted priority queue which might reallocate memory and which rarely spawns a second thread.

How about you give us an example of a class with a few methods, something that you would actually use in real life?
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals