On 10/23/23 10:05 AM, Bonita Montero wrote:
> Am 22.10.2023 um 16:12 schrieb Richard Damon:
>
>> On 10/21/23 9:53 PM, Bonita Montero wrote:
>
>>> The lambda can have an arbitrary size, it is always inlined.
>
>> Your lambda has a fixed code, not arbitrary size.
>
> What I wanted to say is that the lambda's size can be arbitrary
> without having s separate invoker.

So? In this case we got an invoker, because we needed something to
handle the calling convention difference.

>
>> In fact, it is likely that it was because your particular lambda was
>> small, that it was made to be inline.
>
> I did my own index_sequence<...> vs. function-object loop-unrolling
> with 1'000 increments of an atomic_char inside the lambda; it was
> still inlined.

So? The compiler gets to decide under what conditions it wants to inline
the code. Especially if it can see that the lambda isn't used in many
places.

>
>> Lambdas define a function object, which can be created inline or out
>> of line.
>
> The calling operator of a lambda is inline if it is mutable or
> const inline if it is non-mutable. But we don't discuss C++ but
> the behaviour of a specific  platform.
>

You seem to be confusing the calling via a pointer to the lambda, vs the
actual calling of the lambda.

A "Mutable" lambda means the lambda can modify the parameters it has
captured. That dosn't affect being inline or not.

ALso, THIS NEWGROUP (comp.lang.c++) is about generic C++ behavior, not
platform specific behavior. Maybe you should be posting in a group that
IS about that platform.

Am 23.10.2023 um 19:40 schrieb Richard Damon:

> So? In this case we got an invoker, because we needed something to
> handle the calling convention difference.

It's called invoker, but the actual lambda is always inlined.
So this term is misleading here.

> So? The compiler gets to decide under what conditions it wants to inline
> the code. Especially if it can see that the lambda isn't used in many
> places.

Each atomic increment is two instruction, i.e. I've got 2.000
instructions in the actual lambda. If the compiler doesn't inline
that anyway it does this never. Try it yourself on Godbolt if you
want to manage to have s separate invoker.

>> Lambdas define a function object, which can be created inline or out
of line.

> You seem to be confusing the calling via a pointer to the lambda, vs the
> actual calling of the lambda.

You went off topic and I responded. See what you said above.

> A "Mutable" lambda means the lambda can modify the parameters it has
> captured. That dosn't affect being inline or not.

I didn't say that.

> ALso, THIS NEWGROUP (comp.lang.c++) is about generic C++ behavior, not
> platform specific behavior. ...

That's your opinion.

On 10/24/23 7:03 AM, Bonita Montero wrote:
> Am 23.10.2023 um 19:40 schrieb Richard Damon:
>
>> So? In this case we got an invoker, because we needed something to
>> handle the calling convention difference.
>
> It's called invoker, but the actual lambda is always inlined.
> So this term is misleading here.

Why do you say that? The "invoker" is a function created to invoke the
designated function in an environment (calling convention) that the
function can not directly handle.

"invoking" doesn't need a "call" instruction, as when you invoke an
"inline" function, the function is just put there.

Note also, the fact that you are agreeing that this code was an inline
expansion leads to the questions, what is it inline expanded into, the
answer to that are the two invokers that handle the calling convention
mismatch. Thus we don't have two versions of the lambda recompiled to
different calling conventions, but two inline instances of the exact
same lambda, embedded in two invokers that have different calling
conventions.

>
>> So? The compiler gets to decide under what conditions it wants to
>> inline the code. Especially if it can see that the lambda isn't used
>> in many places.
>
> Each atomic increment is two instruction, i.e. I've got 2.000
> instructions in the actual lambda. If the compiler doesn't inline
> that anyway it does this never. Try it yourself on Godbolt if you
> want to manage to have s separate invoker.
>
> >> Lambdas define a function object, which can be created inline or out
> of line.
>
>> You seem to be confusing the calling via a pointer to the lambda, vs
>> the actual calling of the lambda.
>
> You went off topic and I responded. See what you said above.
>
>> A "Mutable" lambda means the lambda can modify the parameters it has
>> captured. That dosn't affect being inline or not.
>
> I didn't say that.

You said:

> The calling operator of a lambda is inline if it is mutable or
> const inline if it is non-mutable. But we don't discuss C++ but
> the behaviour of a specific platform.

So, you said that mutability affected inlining.

So, I guess you don't know what you are saying.

>
>> ALso, THIS NEWGROUP (comp.lang.c++) is about generic C++ behavior, not
>> platform specific behavior. ...
>
> That's your opinion.
>
>

That's the newsgroup charter, not

Am 24.10.2023 um 16:28 schrieb Richard Damon:

> Why do you say that? The "invoker" is a function created to invoke the
> designated function in an environment (calling convention) that the
> function can not directly handle.

The actual lambda is always inlined.

> "invoking" doesn't need a "call" instruction, as when you invoke an
> "inline" function, the function is just put there.

Then the term in invoker doesn't make sense.

>> The calling operator of a lambda is inline if it is mutable or
>> const inline if it is non-mutable. But we don't discuss C++ but
>> the behaviour of a specific  platform.

> So, you said that mutability affected inlining.

No, you went off-topic and I responeded to that.
Then you made the connection to the actual topic, not me.

Richard Damon <richard@damon-family.org> writes:
>On 10/24/23 7:03 AM, Bonita Montero wrote:
>> Am 23.10.2023 um 19:40 schrieb Richard Damon:
>>
>>> So? In this case we got an invoker, because we needed something to
>>> handle the calling convention difference.
>>
>> It's called invoker, but the actual lambda is always inlined.
>> So this term is misleading here.
>
>Why do you say that? The "invoker" is a function created to invoke the
>designated function in an environment (calling convention) that the
>function can not directly handle.

This is often also called a trampoline.

On 10/24/23 8:01 AM, Bonita Montero wrote:
> Am 24.10.2023 um 16:28 schrieb Richard Damon:
>
>> Why do you say that? The "invoker" is a function created to invoke the
>> designated function in an environment (calling convention) that the
>> function can not directly handle.
>
> The actual lambda is always inlined.

Then you agree that there is ONE lambda function (inlined twice) inlined
within two invoker wrappers, not two versions of the lambda "compiled'
with different calling conventions different than the one it was
declared with.

>
>> "invoking" doesn't need a "call" instruction, as when you invoke an
>> "inline" function, the function is just put there.
>
> Then the term in invoker doesn't make sense.

Then "calling a function" that is inline doesn't make sense either.

In fact, "invoking" has less connotation of using a phyical "CALL"
instruction than the term call.

To invoke something is to make it happen. That doesn't imply calling it.

>
>>> The calling operator of a lambda is inline if it is mutable or
>>> const inline if it is non-mutable. But we don't discuss C++ but
>>> the behaviour of a specific  platform.
>
>> So, you said that mutability affected inlining.
>
> No, you went off-topic and I responeded to that.
> Then you made the connection to the actual topic, not me.
>

Maybe you don't understand enough to understand the topicality of my
statement.

YOU claimed "mutability" affected inlining.
I pointed out that it isn't defined to do that.

On 10/24/23 8:25 AM, Scott Lurndal wrote:
> Richard Damon <richard@damon-family.org> writes:
>> On 10/24/23 7:03 AM, Bonita Montero wrote:
>>> Am 23.10.2023 um 19:40 schrieb Richard Damon:
>>>
>>>> So? In this case we got an invoker, because we needed something to
>>>> handle the calling convention difference.
>>>
>>> It's called invoker, but the actual lambda is always inlined.
>>> So this term is misleading here.
>>
>> Why do you say that? The "invoker" is a function created to invoke the
>> designated function in an environment (calling convention) that the
>> function can not directly handle.
>
> This is often also called a trampoline.
>

Yes, but since the program map showed a name of invoker, that is the
term being used.

I think Bonita might have a brain melt to talk about a trampoline named
with the term invoker.

Am 24.10.2023 um 17:28 schrieb Richard Damon:

> Then you agree that there is ONE lambda function (inlined twice) inlined
> within two invoker wrappers, not two versions of the lambda "compiled'
> with different calling conventions different than the one it was
> declared with.

It's two functions with two calling conventions sharing the same data.
An invoker is some kind of stub-code for each calling convention calling
a shared function; so the term invoker is misleading here.

> YOU claimed "mutability" affected inlining.

That's the connection you made.

On 2023-10-24, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 23.10.2023 um 19:40 schrieb Richard Damon:
>
>> So? In this case we got an invoker, because we needed something to
>> handle the calling convention difference.
>
> It's called invoker, but the actual lambda is always inlined.

Well, that's an about face. Near the start of the topic you were
vehemently denying that there was inlining.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-10-24, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 24.10.2023 um 16:28 schrieb Richard Damon:
>
>> Why do you say that? The "invoker" is a function created to invoke the
>> designated function in an environment (calling convention) that the
>> function can not directly handle.
>
> The actual lambda is always inlined.
>
Try to compile without optimisations...

--

7-77-777, Evil Sinner!
https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/

Am 24.10.2023 um 18:34 schrieb Kaz Kylheku:
> On 2023-10-24, Bonita Montero <Bonita.Montero@gmail.com> wrote:

>> Am 23.10.2023 um 19:40 schrieb Richard Damon:

>> It's called invoker, but the actual lambda is always inlined.

> Well, that's an about face. Near the start of the topic you were
> vehemently denying that there was inlining.

An invoker is some kind of stub-/proxy-code, there's nothing
like that here.

On 10/24/23 9:27 AM, Bonita Montero wrote:
> Am 24.10.2023 um 17:28 schrieb Richard Damon:
>
>> Then you agree that there is ONE lambda function (inlined twice)
>> inlined within two invoker wrappers, not two versions of the lambda
>> "compiled' with different calling conventions different than the one
>> it was declared with.
>
> It's two functions with two calling conventions sharing the same data.
> An invoker is some kind of stub-code for each calling convention calling
> a shared function; so the term invoker is misleading here.

But that is EXACTLY what is happening.

We have two "stub" functions, the two "invoker" functions, one for each
calling convention, "calling" (via inline expansion) the shared function.

How does that not match what you see?

>
>> YOU claimed "mutability" affected inlining.
>
> That's the connection you made.
>

Am 24.10.2023 um 18:40 schrieb Branimir Maksimovic:

> Try to compile without optimisations...

This could only make a difference where the parameters are
trivial types. Otherwise objects would have to be copied
and you would have side effects like allocation errors.

Am 24.10.2023 um 19:05 schrieb Richard Damon:

> But that is EXACTLY what is happening.

No, there's no stub-/proxy-code, it's like you implemented
two idential functions with different calling conventions.

On 10/24/23 10:08 AM, Bonita Montero wrote:
> Am 24.10.2023 um 19:05 schrieb Richard Damon:
>
>> But that is EXACTLY what is happening.
>
> No, there's no stub-/proxy-code, it's like you implemented
> two idential functions with different calling conventions.
>

So, how is that different than two stubs with two copies of the same
inline code?

Since they are named that way, it seems to be what it is.

Am 24.10.2023 um 19:39 schrieb Richard Damon:

> So, how is that different than two stubs with two copies of the same
> inline code?

It's not copied code as you can see from my disassembly.

On 2023-10-24, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 24.10.2023 um 19:39 schrieb Richard Damon:
>
>> So, how is that different than two stubs with two copies of the same
>> inline code?
>
> It's not copied code as you can see from my disassembly.

It is quite usual for calls to inline functions not to appear identical.
The code is integrated into the caller, and then subject to
transformations as if were part of the caller's code.

Differences in calling convention would be something handled close to
the compiler code-generating back end.

You should re-examine critically what you mean by "compile twice",
and try to formalize it.

Compiling is everything from recognizing preprocessor tokens and
expanding macros and directives, to writing a .o or .obj file to disk;
even linking objects together to make an executable is sometimes
discussed as part of "compiling".

Code motion like loop unrolling and inlining is not usually discussed in
terms of "compiling twice", though it probaby does result in some
compiler passes being done twice on the different copies of the code.

If by "compiled twice" you mean that some code-generating back end
had to apply its work twice to the copies of the code, you are are
almost certainly right.

The idea that what is going on that code is distinct from inlining (that
"twice compiling" is going on there, but not in inlining) doesn't hold
water.

What most likely happened is this: because of the volatile function
pointer the compiler generated thunks which call the lambda (those
"invokers"):

We can show that using pseudo-code:

Reformatted original, minus header file and namespace boilerplate:

int main()
{
auto lambda = []( int a ) -> int
{
thread_local int i = 0;
return i++ + a;
};

int (__fastcall *volatile pFnFastcall)( int ) = lambda;
int (__stdcall *volatile pFnStdcall)( int ) = lambda;

cout << pFnFastcall( 10 ) << endl;
cout << pFnStdcall( 9 ) << endl;
}

What the compiler might have done, shown as pseudo-code:

int main()
{
auto lambda = []( int a ) -> int
{
thread_local int i = 0;
return i++ + a;
};

// hypothetical, compiler-generated code schema:

auto __notinline __fastcall invoker001 = []( int a ) -> int
{
return lambda(a); // lambda gets inlined
};

auto __notinline __stdcall invoker002 = []( int a ) -> int
{
return lambda(a); // lambda gets inlined
};

int (__fastcall *volatile pFnFastcall)( int ) = invoker001;
int (__stdcall *volatile pFnStdcall)( int ) = invoker002;

cout << pFnFastcall( 10 ) << endl;
cout << pFnStdcall( 9 ) << endl;
}

The invokers are real functions which are called. They inline
the lambda.

The invokers have matching calling conventions, propagated from
the volatile pointers. So that's where the adaptation comes from
to the calling conventions.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/14/2023 11:54 AM, Paavo Helde wrote:
> 14.10.2023 21:33 Chris M. Thomasson kirjutas:
>> On 10/12/2023 11:50 PM, Bonita Montero wrote:
>>> Am 13.10.2023 um 05:50 schrieb Chris M. Thomasson:
>>>> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>
>>>>>> #include <iostream>
>>>>>>
>>>>>> using namespace std;
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>     auto lambda = []( int a ) -> int
>>>>>>     {
>>>>>>         thread_local int i = 0;
>>>>>>         return i++ + a;
>>>>>>     };
>>>>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>>>>     cout << pFnFastcall( 10 ) << endl;
>>>>>>     cout << pFnStdcall( 9 ) << endl;
>>>>>> }
>>
>> 10 10 is a hint...
>
> I also got 10 10, first in my head, and my compiler agreed as well
> (VS2022).

Not sure what the point of Bonita's post was. thread_local is going to
the thread calling main here. All of the rest is just moronic fluff.

10
10

is correct.

Am 24.10.2023 um 21:48 schrieb Kaz Kylheku:

> It is quite usual for calls to inline functions not to appear identical.

That's true in this case because the "invoker" gets its values in
a different way. Nevertheless the term invoker is misleading if the
"invoked" function is always inlined. I did some loop unrolling inside
the lambda, producing about 2.000 instructions and the lambda was still
inlined. I guess If MSVC doesn't have a separate invoker with so much
code there's never a separate invoker. And with non-trivial parameters
there might be unexpectedd side effects if there's a non-inlined called
function like an out of memory error. So I gues MS knows that and con-
siders calling a separate functio too dangerous or intransparent.

Am 25.10.2023 um 00:53 schrieb Chris M. Thomasson:

> Not sure what the point of Bonita's post was. thread_local is going to
> the thread calling main here. All of the rest is just moronic fluff.

Someone might expect that the thread_local or static variables
are not shared among the differernt instantiations of the calling
operator as with a generic calling operator.

On 10/25/23 1:54 AM, Bonita Montero wrote:
> Am 24.10.2023 um 21:48 schrieb Kaz Kylheku:
>
>> It is quite usual for calls to inline functions not to appear identical.
>
> That's true in this case because the "invoker" gets its values in
> a different way. Nevertheless the term invoker is misleading if the
> "invoked" function is always inlined. I did some loop unrolling inside
> the lambda, producing about 2.000 instructions and the lambda was still
> inlined. I guess If MSVC doesn't have a separate invoker with so much
> code there's never a separate invoker. And with non-trivial parameters
> there might be unexpectedd side effects if there's a non-inlined called
> function like an out of memory error. So I gues MS knows that and con-
> siders calling a separate functio too dangerous or intransparent.
>

Yes, "invoker" may be a bit misleading, but it is the term that was
chosen, and the terminology doesn't change just because the invoked
function happens to be inlined.

As someone else mentioned, perhaps a more common term is "trampoline",
but that term is longer, and actually isn't as descriptive of a term.

On 10/25/23 6:07 AM, Bonita Montero wrote:
> Am 25.10.2023 um 00:53 schrieb Chris M. Thomasson:
>
>> Not sure what the point of Bonita's post was. thread_local is going to
>> the thread calling main here. All of the rest is just moronic fluff.
>
> Someone might expect that the thread_local or static variables
> are not shared among the differernt instantiations of the calling
> operator as with a generic calling operator.
>
>

Maybe, but they would be wrong.

After all, for a "generic" lambda, each variation is really a different
function (just like a template function), but each instance of a GIVEN
instance of the "generic" lambda, just like the non-generic lambda, or
even an ordinary function, when inlined MUST share static or
thread_local variables.

Am 25.10.2023 um 17:43 schrieb Richard Damon:

> Yes, "invoker" may be a bit misleading, but it is the term that was
> chosen, and the terminology doesn't change just because the invoked
> function happens to be inlined.

The term becomes rather metaphoric with that.

Am 25.10.2023 um 17:43 schrieb Richard Damon:

> After all, for a "generic" lambda, each variation is really a different
> function (just like a template function), but each instance of a GIVEN
> instance of the "generic" lambda, just like the non-generic lambda, or
> even an ordinary function, when inlined MUST share static or
> thread_local variables.

I would also have thought it acceptable if each "instance" of
the lambda had its own static and thread-local variables for
each calling convention. In practice, it would be very atypical
if you actually instantiate the lambda with several calling
conventions.

On 10/25/23 9:01 AM, Bonita Montero wrote:
> Am 25.10.2023 um 17:43 schrieb Richard Damon:
>
>> After all, for a "generic" lambda, each variation is really a
>> different function (just like a template function), but each instance
>> of a GIVEN instance of the "generic" lambda, just like the non-generic
>> lambda, or even an ordinary function, when inlined MUST share static
>> or thread_local variables.
>
> I would also have thought it acceptable if each "instance" of
> the lambda had its own static and thread-local variables for
> each calling convention. In practice, it would be very atypical
> if you actually instantiate the lambda with several calling
> conventions.

The key point is that for functions that are inlined, each inlined
"instance" of the function doesn't get new shared static/thread-local
variables. This is REQUIRED as inlining isn't allowed to change the
visible behavior of the function, but is just an optimization.

Your multiple "instances" are all logically part of the same function.
Your thought process that you have two different versions of the lambda
with different calling conventions is just incorrect.

You have one version of the lambda, with the cdecl calling convention
(since no convention was specified) used in both "instances". Each
instance is actually an invoker/trampoline function with the specified
calling convention, using the one defined lambda function, which happens
to get inlined. So, perhaps at first glance it looks like there are two
different version of the lambda function, but by the definitions of the
Standard, there is one version, that has been inlined in two places
within two different calling convention adaptor functions.