Re: C23 thoughts and opinions

On 28/05/2024 02:33, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

On 27/05/2024 01:17, Keith Thompson wrote:

[...]

Here's how I personally would have preferred for #embed to be
specified:
- As in current C23 drafts, #embed with no parameters must operate
*as
    if* it expanded to a comma-delimited list of integer constant
    expressions.
- With no parameters, both the common cases (initializing an array of
    characters) and odd cases (e.g., initializing a struct object with
    varying types and sizes of members) must work as specified.
- A standard-defined parameter allows control over optimization.
The parameter can be "optimize(true)" or "optimize(false)".
"optimize(false)" has no formal effect, but the compiler *should*
generate the canonical sequence of constants.
"optimize(true)" causes undefined behavior if #embed is used in a
context other than the initialization of an array of character type.

>
I disagree here.  I want the compiler to generate the "as if" results
regardless of any optimisation, working as currently specified.  And
/if/ the compiler is able to optimise the #embed, then I want it to do
so automatically - I see no situation in which I would ever want
"optimize(false)".

 The issue I'm trying to address (very prematurely, no doubt) is
that the decision of whether to optimize #embed vs. generating the
naive comma-separated sequence is difficult to formalize, and easy
to get wrong in corner cases. 

That's probably true.  I would expect compiler implementations to optimise #embed only in cases where it is very clear (and at the very least, initialising a const array of char will fall into that category), and only when the preprocessor and compiler can coordinate it.  Fallback will be using integer literal constants.  I can't see any reason why that fallback should be slower than using xxd (or similar) and #include, so #embed should always be no slower than existing methods but sometimes very much faster.
If optimisation was controlled or specified by something in the standard (such as your suggested "optimize()" parameter), then it would have to be formalized - leaving it to the implementation, which can document it as "best effort", entirely avoids the difficulty of specifying it.  The only formalization needed is to say that it will always act "as if" it generated a comma-separated sequence.

"restrict" is another performance
hint whose only formal effect is to introduce undefined behavior
if you use it incorrectly.

Yes, it is.  (And I believe C23 has re-written some of the description of "restrict" - not to change its behaviour, but to make it clearer.  I have not looked at that bit as yet.)  But again, I can't see how any discussion of optimisation of #embed affects the behaviour and therefore any UB.  The result is /always/ the same - it's just the compile time that may differ.

 Let's say I define an array of a 1-byte enumeration type, initialized
with #embed for a very large binary file.  Maybe one compiler recognizes
this as a case where it can perform the optimization, and another
doesn't.

Yes, that may be the case.

 If I can tell the compiler "trust me, I'm using this to
initialize raw byte data, and I'll take responsibility if I get it
wrong", I can see that being useful.

What do you mean by "wrong" here?  Both compilers will give identical results.  The only difference is that one will do so faster than the other.

 And maybe "optimize" isn't the best name.  Perhaps "raw_bytes"?

"raw_bytes" makes no sense to me.  I can see that "optimize" might be confusing - normally the word refers to the speed (and/or memory usage) of the generated code, while here it refers to the speed (and/or memory usage) of the compilation.

 Without some kind of programmer control, I'm concerned that the rules
for defining an array so #embed will be correctly optimized will be
spread as lore rather than being specified anywhere.
 

They might, but I really do not think that is so important, since they will not affect the generated results.