Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Reid Kleckner-2
Hi LLVM folks,

To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able
to take the address of an outgoing call argument slot.  This is

Problem
-------

On Windows, C structs are pushed right onto the stack in line with the other
arguments.  In LLVM, we use byval to model this, and it works for C structs.
However, C++ records are also passed this way, and reusing byval for C++ records
breaks C++ object identity rules.

In order to implement the ABI properly, we need a way to get the address of the
argument slot *before* we start the call, so that we can either construct the
object in place on the stack or at least call its copy constructor.

This is further complicated by the possibility of nested calls passing arguments by
value.  A good general case to think about is a binary tree of calls that take
two arguments by value and return by value:

  struct A { int a; };
  A foo(A, A);
  foo(foo(A(), A()), foo(A(), A()));

To complete the outer call to foo, we have to adjust the stack for its outgoing
arguments before the inner calls to foo, and arrange for the sret pointers to
point to those slots.

To make this even more complicated, C++ methods are typically callee cleanup (thiscall), but free functions are caller cleanup (cdecl).

Features
--------

A few weeks ago, I sat down with some folks at Google and we came up with this
proposal, which tries to add the minimum set of LLVM IL features to make this
possible.

1. Allow alloca instructions to use llvm.stacksave values to indicate scoping.

This creates an SSA dependence between the alloca instruction and the
stackrestore instruction that prevents optimizers from accidentally reordering
them in ways that don't verify.  llvm.stacksave in this case is taking on a role
similar to CALLSEQ_START in the selection dag.

LLVM can also apply this to dynamic allocas from inline functions to ensure that
optimizers don't move them.

2. Add an 'alloca' attribute for parameters.

Only an alloca value can be passed to a parameter with this attribute.  It
cannot be bitcasted or GEPed.  An alloca can only be passed in this way once.
It can be passed as a normal pointer to any number of other functions.

Aside from allocas bounded by llvm.stacksave and llvm.stackrestore calls, there
can be no allocas between the creation of an alloca passed with this attribute
and its associated call.

3. Add a stackrestore field to call and invoke instructions.

This models calling conventions which do their own cleanup, and ensures that
even after optimizations have perturbed the IR, we don't consider the allocas to
be live.  For caller cleanup conventions, while the callee may have called
destructors on its arguments, the allocas can be considered live until the stack
restore.

Example
-------

A single call to foo, assuming it is stdcall, would be lowered something like:

%res = alloca %struct.A
%base = llvm.stacksave()
%arg1 = alloca %struct.A, stackbase %base
%arg2 = alloca %struct.A, stackbase %base
call @A_ctor(%arg1)
call @A_ctor(%arg2)
call x86_stdcallcc @foo(%res sret, %arg1 alloca, %arg2 alloca), stackrestore %base

If control does not flow through a call or invoke with a stackrestore field,
then manual calls to llvm.stackrestore must be emitted before another call or
invoke can use an 'alloca' argument.  The manual stack restore call ends the
lifetime of the allocas.  This is necessary to handle unwind edges from argument
expression evaluation as well as the case where foo is not callee cleanup.

Implementation
--------------

By starting out with the stack save and restore intrinsics, we can hopefully
approach a slow but working implementation sooner rather than later.  The work
should mostly be in the verifier, the IR, its parser, and the x86 backend.

I don't plan to start working on this immediately, but over the long run this will be really important to support well.

---

That's all!  Please send feedback!  This is admittedly a really complicated
feature and I'm sorry for inflicting it on the LLVM community, but it's
obviously beyond my control.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Duncan Sands
Hi Reid,

On 25/07/13 23:38, Reid Kleckner wrote:

> Hi LLVM folks,
>
> To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able
> to take the address of an outgoing call argument slot.  This is
> http://llvm.org/PR5064 .
>
> Problem
> -------
>
> On Windows, C structs are pushed right onto the stack in line with the other
> arguments.  In LLVM, we use byval to model this, and it works for C structs.
> However, C++ records are also passed this way, and reusing byval for C++ records
> breaks C++ object identity rules.
>
> In order to implement the ABI properly, we need a way to get the address of the
> argument slot *before* we start the call, so that we can either construct the
> object in place on the stack or at least call its copy constructor.

what does GCC do?

Ciao, Duncan.

>
> This is further complicated by the possibility of nested calls passing arguments by
> value.  A good general case to think about is a binary tree of calls that take
> two arguments by value and return by value:
>
>    struct A { int a; };
>    A foo(A, A);
>    foo(foo(A(), A()), foo(A(), A()));
>
> To complete the outer call to foo, we have to adjust the stack for its outgoing
> arguments before the inner calls to foo, and arrange for the sret pointers to
> point to those slots.
>
> To make this even more complicated, C++ methods are typically callee cleanup
> (thiscall), but free functions are caller cleanup (cdecl).
>
> Features
> --------
>
> A few weeks ago, I sat down with some folks at Google and we came up with this
> proposal, which tries to add the minimum set of LLVM IL features to make this
> possible.
>
> 1. Allow alloca instructions to use llvm.stacksave values to indicate scoping.
>
> This creates an SSA dependence between the alloca instruction and the
> stackrestore instruction that prevents optimizers from accidentally reordering
> them in ways that don't verify.  llvm.stacksave in this case is taking on a role
> similar to CALLSEQ_START in the selection dag.
>
> LLVM can also apply this to dynamic allocas from inline functions to ensure that
> optimizers don't move them.
>
> 2. Add an 'alloca' attribute for parameters.
>
> Only an alloca value can be passed to a parameter with this attribute.  It
> cannot be bitcasted or GEPed.  An alloca can only be passed in this way once.
> It can be passed as a normal pointer to any number of other functions.
>
> Aside from allocas bounded by llvm.stacksave and llvm.stackrestore calls, there
> can be no allocas between the creation of an alloca passed with this attribute
> and its associated call.
>
> 3. Add a stackrestore field to call and invoke instructions.
>
> This models calling conventions which do their own cleanup, and ensures that
> even after optimizations have perturbed the IR, we don't consider the allocas to
> be live.  For caller cleanup conventions, while the callee may have called
> destructors on its arguments, the allocas can be considered live until the stack
> restore.
>
> Example
> -------
>
> A single call to foo, assuming it is stdcall, would be lowered something like:
>
> %res = alloca %struct.A
> %base = llvm.stacksave()
> %arg1 = alloca %struct.A, stackbase %base
> %arg2 = alloca %struct.A, stackbase %base
> call @A_ctor(%arg1)
> call @A_ctor(%arg2)
> call x86_stdcallcc @foo(%res sret, %arg1 alloca, %arg2 alloca), stackrestore %base
>
> If control does not flow through a call or invoke with a stackrestore field,
> then manual calls to llvm.stackrestore must be emitted before another call or
> invoke can use an 'alloca' argument.  The manual stack restore call ends the
> lifetime of the allocas.  This is necessary to handle unwind edges from argument
> expression evaluation as well as the case where foo is not callee cleanup.
>
> Implementation
> --------------
>
> By starting out with the stack save and restore intrinsics, we can hopefully
> approach a slow but working implementation sooner rather than later.  The work
> should mostly be in the verifier, the IR, its parser, and the x86 backend.
>
> I don't plan to start working on this immediately, but over the long run this
> will be really important to support well.
>
> ---
>
> That's all!  Please send feedback!  This is admittedly a really complicated
> feature and I'm sorry for inflicting it on the LLVM community, but it's
> obviously beyond my control.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Anton Korobeynikov-2
>> object in place on the stack or at least call its copy constructor.
>
>
> what does GCC do?
Nothing. It does not support MSVC ABI.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Duncan Sands
On 29/07/13 15:30, Anton Korobeynikov wrote:
>>> object in place on the stack or at least call its copy constructor.
>>
>>
>> what does GCC do?
> Nothing. It does not support MSVC ABI.

Maybe we shouldn't either :)  So the ABI requires the struct to be pushed on the
stack by the caller along with the other parameters, and what's more it requires
the caller to execute some code on that copy, in place on the stack, before
performing the call.  Is that right?

Ciao, Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Reid Kleckner-2
On Mon, Jul 29, 2013 at 9:40 AM, Duncan Sands <[hidden email]> wrote:
On 29/07/13 15:30, Anton Korobeynikov wrote:
object in place on the stack or at least call its copy constructor.


what does GCC do?
Nothing. It does not support MSVC ABI.

Maybe we shouldn't either :)  So the ABI requires the struct to be pushed on the
stack by the caller along with the other parameters, and what's more it requires
the caller to execute some code on that copy, in place on the stack, before
performing the call.  Is that right?

Just calling the copy ctor is the bare minimum needed to support the ABI.  cl.exe uses a more efficient lowering that evaluates the arguments right to left directly into the outgoing argument stack slots.  It lowers following call to bar to something like:

struct A {int x; int y;};
A foo();
void bar(int, A, int);
...
bar(0xdead, foo(), 0xbeef);

x86_32 pseudo intel asm:

push 0xdead
sub esp, 8
push esp  # sret arg for foo
call foo
add esp, 4 # clear sret arg
push 0xbeef
call bar
add 16 # clear args

With the current proposal, LLVM would generate code that adjusts the stack once to begin the call, and once more to end it.  Initially, it would do a blind SP restore, but that can be optimized to a constant SP adjustment.  Arguments will still be evaluated left to right and will be stored into the special alloca outgoing argument slots.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Duncan Sands
Hi Reid,

On 29/07/13 16:36, Reid Kleckner wrote:

> On Mon, Jul 29, 2013 at 9:40 AM, Duncan Sands <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 29/07/13 15:30, Anton Korobeynikov wrote:
>
>                 object in place on the stack or at least call its copy constructor.
>
>
>
>             what does GCC do?
>
>         Nothing. It does not support MSVC ABI.
>
>
>     Maybe we shouldn't either :)  So the ABI requires the struct to be pushed on the
>     stack by the caller along with the other parameters, and what's more it requires
>     the caller to execute some code on that copy, in place on the stack, before
>     performing the call.  Is that right?
>
>
> Just calling the copy ctor is the bare minimum needed to support the ABI.
>   cl.exe uses a more efficient lowering that evaluates the arguments right to
> left directly into the outgoing argument stack slots.  It lowers following call
> to bar to something like:
>
> struct A {int x; int y;};
> A foo();
> void bar(int, A, int);
> ...
> bar(0xdead, foo(), 0xbeef);
>
> x86_32 pseudo intel asm:
>
> push 0xdead
> sub esp, 8
> push esp  # sret arg for foo
> call foo
> add esp, 4 # clear sret arg
> push 0xbeef
> call bar

I got confused by your example.  Is the struct passed on the stack, amongst the
other parameters, or can it be allocated somewhere else and a pointer to it
passed?  Because in your example it isn't clear to me how the return value of
foo() is being passed to bar().

Ciao, Duncan.

> add 16 # clear args
>
> With the current proposal, LLVM would generate code that adjusts the stack once
> to begin the call, and once more to end it.  Initially, it would do a blind SP
> restore, but that can be optimized to a constant SP adjustment.  Arguments will
> still be evaluated left to right and will be stored into the special alloca
> outgoing argument slots.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Reid Kleckner-2
On Mon, Jul 29, 2013 at 10:45 AM, Duncan Sands <[hidden email]> wrote:
Hi Reid,


On 29/07/13 16:36, Reid Kleckner wrote:
On Mon, Jul 29, 2013 at 9:40 AM, Duncan Sands <[hidden email]
<mailto:[hidden email]>> wrote:

    On 29/07/13 15:30, Anton Korobeynikov wrote:

                object in place on the stack or at least call its copy constructor.



            what does GCC do?

        Nothing. It does not support MSVC ABI.


    Maybe we shouldn't either :)  So the ABI requires the struct to be pushed on the
    stack by the caller along with the other parameters, and what's more it requires
    the caller to execute some code on that copy, in place on the stack, before
    performing the call.  Is that right?


Just calling the copy ctor is the bare minimum needed to support the ABI.
  cl.exe uses a more efficient lowering that evaluates the arguments right to
left directly into the outgoing argument stack slots.  It lowers following call
to bar to something like:

struct A {int x; int y;};
A foo();
void bar(int, A, int);
...
bar(0xdead, foo(), 0xbeef);

x86_32 pseudo intel asm:

push 0xdead
sub esp, 8
push esp  # sret arg for foo
call foo
add esp, 4 # clear sret arg
push 0xbeef
call bar

I got confused by your example.  Is the struct passed on the stack, amongst the
other parameters, or can it be allocated somewhere else and a pointer to it
passed?  Because in your example it isn't clear to me how the return value of
foo() is being passed to bar().

Yes, the struct is passed amongst the other parameters.  LLVM already supports passing C structs this way using byval, but it emits a memcpy in the backend, which breaks C++ objects.

foo() is returning an A struct via the usual hidden sret parameter.  The "push esp" is taking the address of the struct's outgoing arg slot and passing it to foo().

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Duncan Sands
Hi Reid,

>         struct A {int x; int y;};
>         A foo();
>         void bar(int, A, int);
>         ...
>         bar(0xdead, foo(), 0xbeef);
>
>         x86_32 pseudo intel asm:
>
>         push 0xdead
>         sub esp, 8
>         push esp  # sret arg for foo
>         call foo
>         add esp, 4 # clear sret arg
>         push 0xbeef
>         call bar
>
>
>     I got confused by your example.  Is the struct passed on the stack, amongst the
>     other parameters, or can it be allocated somewhere else and a pointer to it
>     passed?  Because in your example it isn't clear to me how the return value of
>     foo() is being passed to bar().
>
>
> Yes, the struct is passed amongst the other parameters.  LLVM already supports
> passing C structs this way using byval, but it emits a memcpy in the backend,
> which breaks C++ objects.
>
> foo() is returning an A struct via the usual hidden sret parameter.  The "push
> esp" is taking the address of the struct's outgoing arg slot and passing it to
> foo().

indeed!  This seems perfectly obvious now that you explained it, sorry for being
dense.

Ciao, Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Óscar Fuentes
In reply to this post by Duncan Sands
Duncan Sands <[hidden email]> writes:

> On 29/07/13 15:30, Anton Korobeynikov wrote:
>>>> object in place on the stack or at least call its copy constructor.
>>>
>>>
>>> what does GCC do?
>> Nothing. It does not support MSVC ABI.
>
> Maybe we shouldn't either :)

Right. What's the point of all the effort devoted to MSVC++ ABI
compatibility when Clang doesn't need it for being a top-notch C++
compiler on Windows?

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Rafael Espíndola
In reply to this post by Reid Kleckner-2
How do you handle this during codegen? One problem is avoid stack
changes (like spills). Another is coordinating things that are using
allocas and those that are not but end up in the stack. Consider

void foo(int arg1, int arg2, int arg3, ....CXXTypeWithCopyConstructor
argn, int argp1...)

You will need an alloca for argn, but the ABI also requires it to be
next to the plain integers that didn' fit in registers, no? This is
part of the reason my suggestion was to have a single opaque object
representing the frame being constructed and a getelementpointer like
abstraction to get pointers out of it.


On 25 July 2013 17:38, Reid Kleckner <[hidden email]> wrote:

> Hi LLVM folks,
>
> To properly implement pass-by-value in the Microsoft C++ ABI, we need to be
> able
> to take the address of an outgoing call argument slot.  This is
> http://llvm.org/PR5064 .
>
> Problem
> -------
>
> On Windows, C structs are pushed right onto the stack in line with the other
> arguments.  In LLVM, we use byval to model this, and it works for C structs.
> However, C++ records are also passed this way, and reusing byval for C++
> records
> breaks C++ object identity rules.
>
> In order to implement the ABI properly, we need a way to get the address of
> the
> argument slot *before* we start the call, so that we can either construct
> the
> object in place on the stack or at least call its copy constructor.
>
> This is further complicated by the possibility of nested calls passing
> arguments by
> value.  A good general case to think about is a binary tree of calls that
> take
> two arguments by value and return by value:
>
>   struct A { int a; };
>   A foo(A, A);
>   foo(foo(A(), A()), foo(A(), A()));
>
> To complete the outer call to foo, we have to adjust the stack for its
> outgoing
> arguments before the inner calls to foo, and arrange for the sret pointers
> to
> point to those slots.
>
> To make this even more complicated, C++ methods are typically callee cleanup
> (thiscall), but free functions are caller cleanup (cdecl).
>
> Features
> --------
>
> A few weeks ago, I sat down with some folks at Google and we came up with
> this
> proposal, which tries to add the minimum set of LLVM IL features to make
> this
> possible.
>
> 1. Allow alloca instructions to use llvm.stacksave values to indicate
> scoping.
>
> This creates an SSA dependence between the alloca instruction and the
> stackrestore instruction that prevents optimizers from accidentally
> reordering
> them in ways that don't verify.  llvm.stacksave in this case is taking on a
> role
> similar to CALLSEQ_START in the selection dag.
>
> LLVM can also apply this to dynamic allocas from inline functions to ensure
> that
> optimizers don't move them.
>
> 2. Add an 'alloca' attribute for parameters.
>
> Only an alloca value can be passed to a parameter with this attribute.  It
> cannot be bitcasted or GEPed.  An alloca can only be passed in this way
> once.
> It can be passed as a normal pointer to any number of other functions.
>
> Aside from allocas bounded by llvm.stacksave and llvm.stackrestore calls,
> there
> can be no allocas between the creation of an alloca passed with this
> attribute
> and its associated call.
>
> 3. Add a stackrestore field to call and invoke instructions.
>
> This models calling conventions which do their own cleanup, and ensures that
> even after optimizations have perturbed the IR, we don't consider the
> allocas to
> be live.  For caller cleanup conventions, while the callee may have called
> destructors on its arguments, the allocas can be considered live until the
> stack
> restore.
>
> Example
> -------
>
> A single call to foo, assuming it is stdcall, would be lowered something
> like:
>
> %res = alloca %struct.A
> %base = llvm.stacksave()
> %arg1 = alloca %struct.A, stackbase %base
> %arg2 = alloca %struct.A, stackbase %base
> call @A_ctor(%arg1)
> call @A_ctor(%arg2)
> call x86_stdcallcc @foo(%res sret, %arg1 alloca, %arg2 alloca), stackrestore
> %base
>
> If control does not flow through a call or invoke with a stackrestore field,
> then manual calls to llvm.stackrestore must be emitted before another call
> or
> invoke can use an 'alloca' argument.  The manual stack restore call ends the
> lifetime of the allocas.  This is necessary to handle unwind edges from
> argument
> expression evaluation as well as the case where foo is not callee cleanup.
>
> Implementation
> --------------
>
> By starting out with the stack save and restore intrinsics, we can hopefully
> approach a slow but working implementation sooner rather than later.  The
> work
> should mostly be in the verifier, the IR, its parser, and the x86 backend.
>
> I don't plan to start working on this immediately, but over the long run
> this will be really important to support well.
>
> ---
>
> That's all!  Please send feedback!  This is admittedly a really complicated
> feature and I'm sorry for inflicting it on the LLVM community, but it's
> obviously beyond my control.
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Reid Kleckner-2
On Tue, Jul 30, 2013 at 11:07 AM, Rafael Espíndola <[hidden email]> wrote:
How do you handle this during codegen? One problem is avoid stack
changes (like spills)

I'm not sure I understand your question, but my plan is to basically use a frame pointer when there is a call with an argument using the 'alloca' attribute.  It'll be slow but functional.

Later the backend can be optimized to be clever about spilling through an SP-based memory operand in the presence of stack adjustments.  I don't yet have a concrete plan for this, and it will require more familiarity with the backend than I currently have.

Another is coordinating things that are using
allocas and those that are not but end up in the stack. Consider

void foo(int arg1, int arg2, int arg3, ....CXXTypeWithCopyConstructor
argn, int argp1...)

You will need an alloca for argn, but the ABI also requires it to be
next to the plain integers that didn' fit in registers, no? This is
part of the reason my suggestion was to have a single opaque object
representing the frame being constructed and a getelementpointer like
abstraction to get pointers out of it.

This proposal puts this complexity in the backend.  The backend will lay out the outgoing argument slots as required by the ABI, and alloca pointer will be resolved to point to the appropriate outgoing argument slot.

The verifier will be changed to reject IR with a live alloca between a call site with an alloca-attributed argument and the creation of that alloca.

This will work however:

%s1 = stacksave
%1 = alloca stackbase %s1
%s2 = stacksave
%2 = alloca stackbase %s2
call @foo(%2 alloca)
stackrestore %s2
call @foo(%1 alloca)
stackrestore %s1

Because the %2 alloca is dead due to the stack restore before the second foo call.

I should also mention how this interacts with regparms.   The win64 CC has 4 regparms, and if one of them is a struct, it is passed indirectly.  Users can easily handle that in the frontend, and the backend could reject the alloca attribute on parameters that should be in registers.  I need to double-check what happens for fastcall on x86_32.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Stephen Lin
In reply to this post by Óscar Fuentes
> Right. What's the point of all the effort devoted to MSVC++ ABI
> compatibility when Clang doesn't need it for being a top-notch C++
> compiler on Windows?

I brought up a similar point a little bit earlier, too....

It seems like the only necessary condition for being a first-class
native-code development tool on Windows is to support the platform C
ABI and the subset of the C++ ABI required by COM, and that is the
most that any non-MS compiler on Windows tries to do, so I am
genuinely curious why there is so much effort being spent on the more
esoteric portions of the ABI?

As far as I understand it, the case being considered here is not
supported in COM, which constrains the types of parameter and return
values at ABI boundaries to pointers, simple C types, and some special
cases...

Stephen
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Charles Davis

On Jul 30, 2013, at 12:41 PM, Stephen Lin wrote:

>> Right. What's the point of all the effort devoted to MSVC++ ABI
>> compatibility when Clang doesn't need it for being a top-notch C++
>> compiler on Windows?
>
> I brought up a similar point a little bit earlier, too....
>
> It seems like the only necessary condition for being a first-class
> native-code development tool on Windows is to support the platform C
> ABI and the subset of the C++ ABI required by COM, and that is the
> most that any non-MS compiler on Windows tries to do,
Huh? Intel CC supports the MSVC++ ABI. Zortech (Digital Mars) supports it, too (though the guy who wrote it isn't too proud of that fact--or the fact that he even wrote that compiler to begin with). Heck, even CodeWarrior supported it (as Howard Hinnant might well remember), before Metrowerks sold off their x86 compiler backend. In fact, other than GCC, only Borland and Watcom don't support it, and that's only because they originally developed theirs during the DOS era, before MSVC++ became the de facto standard compiler. (But Watcom also used to support MFC development on Windows, so they might have supported it at one point, too.)
> so I am
> genuinely curious why there is so much effort being spent on the more
> esoteric portions of the ABI?
Because the sad truth is, the Microsoft ABI is the de facto standard on Windows--just as the Itanium ABI is the de facto standard on Linux and Mac OS. Many a third-party DLL was compiled against it, and so were a few first-party ones, like the aforementioned MFC. Not everyone (sadly) has the luxury of recompiling their DLLs to work with an alternative C++ ABI--and I'd imagine it'd be a support nightmare for those that do to have multiple binaries out there in the wild (Welcome to DLL Hell!! :). Seriously, I think they've had enough trouble with multiple versions; I don't think they want to deal with multiple C++ ABIs, too. (Naturally, open source software does not have the first problem, because they *can* just recompile their DLLs to work with GCC/Clang--which they often do. But still, there's a lot of legacy proprietary code out there on Windows, and the fact that open source code can be recompiled does little for the DLL Hell problem.)

The fact that more than one C++ ABI isn't quite compatible with MSVC (not even enough to support COM, in some cases) is the reason Wine (for example) doesn't allow C++ code. (And yes, some of their DLLs really do need to conform to the Microsoft C++ ABI, beyond just COM.) In fact, that was the whole reason that *I* started this little subproject (supporting the MSVC ABI) in the first place. (Though I imagine that at least some of this might have taken place even without me. ;)

You're right that we don't need it to be a great C++ compiler. But we do need it to attract people who'd otherwise use MSVC (if for no other reason than ABI compatibility) to our top-notch compiler.

Chip


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Óscar Fuentes
Charles Davis <[hidden email]> writes:

> Huh? Intel CC supports the MSVC++ ABI. Zortech (Digital Mars) supports
> it, too (though the guy who wrote it isn't too proud of that fact--or
> the fact that he even wrote that compiler to begin with). Heck, even
> CodeWarrior supported it (as Howard Hinnant might well remember),
> before Metrowerks sold off their x86 compiler backend. In fact, other
> than GCC, only Borland and Watcom don't support it, and that's only
> because they originally developed theirs during the DOS era, before
> MSVC++ became the de facto standard compiler. (But Watcom also used to
> support MFC development on Windows, so they might have supported it at
> one point, too.)

MFC is just a library and hence unrelated to the C++ ABI. Borland
produced MFC applications without problem. You need to support some
language extensions, but that's all. Oh, and IIRC you need a license for
using MFC with other compiler than MS. If I'm not mistaken, same
requirement applies to key components such as the C++ runtime/stdlib.

>> so I am
>> genuinely curious why there is so much effort being spent on the more
>> esoteric portions of the ABI?
> Because the sad truth is, the Microsoft ABI is the de facto standard
> on Windows--just as the Itanium ABI is the de facto standard on Linux
> and Mac OS. Many a third-party DLL was compiled against it, and so
> were a few first-party ones, like the aforementioned MFC. Not everyone
> (sadly) has the luxury of recompiling their DLLs to work with an
> alternative C++ ABI--and I'd imagine it'd be a support nightmare for
> those that do to have multiple binaries out there in the wild (Welcome
> to DLL Hell!! :). Seriously, I think they've had enough trouble with
> multiple versions; I don't think they want to deal with multiple C++
> ABIs, too.

Quite the contrary, knowing that Clang's C++ ABI is completely
incompatible with MS is a maintenance *simplification*.

Saying that supporting the MS C++ ABI is an uphill battle is an
understatement (and better say MS C++ ABI*S*, because it evolved over
time and it is known that it will change on future releases.) As far as
I'm concerned, I'll never base my decisions on compiler usage on the
advertisement of MS compatibility by Clang++, becase I *know* that for a
very long time (maybe forever) whatever MS C++ libraries that work with
Clang++ is by luck. That's what happens when you try to implement
compatibility with an undocumented, propietary, complex feature.

> (Naturally, open source software does not have the first problem,
> because they *can* just recompile their DLLs to work with
> GCC/Clang--which they often do. But still, th ere's a lot of legacy
> proprietary code out there on Windows, and the fact that open source
> code can be recompiled does little for the DLL Hell problem.)
>
> The fact that more than one C++ ABI isn't quite compatible with MSVC
> (not even enough to support COM, in some cases) is the reason Wine
> (for example) doesn't allow C++ code. (And yes, some of their DLLs
> really do need to conform to the Microsoft C++ ABI, beyond just COM.)
> In fact, that was the whole reason that *I* started this little
> subproject (supporting the MSVC ABI) in the first place. (Though I
> imagine that at least some of this might have taken place even without
> me. ;)
>
> You're right that we don't need it to be a great C++ compiler. But we
> do need it to attract people who'd otherwise use MSVC (if for no other
> reason than ABI compatibility) to our top-notch compiler.

Of course you are free to work on whatever you wish. I'm not criticizing
your work or anybody else's. However, I'm quite surprised to see how a
great deal of energy is invested on MS C++ ABI compatibility without an
end in sight and with some ticklish areas ahead (MS C++ runtime(s)
support, SEH support, complex LLVM change requirements (this very same
thread)) while Clang++ currently cannot do several basic things on
Windows (which of course are also required for being MS compatible.)
Example: dllexport of C++ classes and templates.

I'm also worried by the damage of claims such as "MS C++ ABI is the
standard on Windows", which conveys the message that until Clang++
supports such ABI it can not be a serious contender on Windows. Which is
blatantly false. Fact is that you need MS C++ ABI compatibility only for
using C++ libraries which lack source code. I doubt that the individuals
and organizations that abide such pitiful state are interested on using
a compiler other than the "industry standard" MSVC++, or that the
success of Clang on Windows depend on them at all.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Rafael Espíndola
In reply to this post by Reid Kleckner-2
> This proposal puts this complexity in the backend.  The backend will lay out
> the outgoing argument slots as required by the ABI, and alloca pointer will
> be resolved to point to the appropriate outgoing argument slot.

OK, so it makes the backend and verifier a bit more complex, but has a
smaller IR extension. That is probably a good tradeoff.

Thanks,
Rafael
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Stephen Lin
In reply to this post by Óscar Fuentes
> Quite the contrary, knowing that Clang's C++ ABI is completely
> incompatible with MS is a maintenance *simplification*.

Yes, for example, as explained by Bjarne once, incompatible name
mangling schemes for ABIs that are not guaranteed to be 100% binary
compatible is a _feature_, not a bug, since it prevents anyone from
even beginning to develop a workflow that relies upon linking possibly
incompatible binaries.

>
> Saying that supporting the MS C++ ABI is an uphill battle is an
> understatement (and better say MS C++ ABI*S*, because it evolved over
> time and it is known that it will change on future releases.) As far as
> I'm concerned, I'll never base my decisions on compiler usage on the
> advertisement of MS compatibility by Clang++, becase I *know* that for a
> very long time (maybe forever) whatever MS C++ libraries that work with
> Clang++ is by luck. That's what happens when you try to implement
> compatibility with an undocumented, propietary, complex feature.

This is my point as well; it just seems odd to spend so much effort to
implement and undocumented ABI with no guarantee of support or
stability (outside of MSVC major version releases). Furthermore, I
feel that, by reinforcing the notion that use of the MSVC++ ABI is
required for development on Windows (when no system-provided libraries
or ABIs require it), Clang developers are hindering the adoption of
Clang on Windows rather than promoting it, since it is unlikely that
any party that is not personally invested in Clang development would
be willing to depend on a backward engineered implementation of a
"required" but undocumented ABI for production use. Furthermore, it
means that Clang will always be behind the curve on Windows, since,
even if MSVC++ ABI support is fully usable one day, no one will be
willing to link it with object files from a new major version of MSVC
without some critical mass of users being guinea pigs first and
ensuring that there are no major bugaboos.

I agree that there is value in supporting implementing full MSVC++
ABI, if it can be done, but it seems like that support can never be
100% complete (or, more to the point, known to be 100% complete)
unless Microsoft itself decides to officially support the
implementation or completely stabilize and document their C++ ABIs.
However, I personally think that it is not only easier, there is more
value in implementing a C++ ABI which is compatible with officially
supported C and COM MSVC++ ABI subsets and consciously _not_
compatible in others way (in particular, which does not even attempt
to link C++ symbols with MSVC++, since that is not required for COM).
This is something that can be made to work and guaranteed (barring
some seriously misguided behavior from Microsoft) to continue to work
stably.

Furthermore, by providing and controlling its own Windows C++ ABI:
Clang can possibly offer something that MSVC *cannot* (and does not
even try to do): a development platform and ecosystem which provides a
stable-over-time C++ ABI and consistent cross-module usage of RTTI,
STL, C++ memory management, etc. (which is dicey even within MSVC
major versions unless the exact same build settings are used, last
time I checked.) This would give someone an active reason to switch to
Clang more than anything else Clang currently offers on Windows.

Stephen
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Chris Lattner-2
This thread is odd to me. It seems that the gist of your guys' argument is that you don't know if we will ever get full support, therefore we don't welcome progress towards that (very useful) goal/feature.

If the specific proposal doesn't make make sense from a design standpoint, that's one thing, but saying we shouldn't take it because of licensing issues with MFC or because it is harmful to be partially (but not fully) compatible with MSVC seems just weird to me.

-Chris

On Jul 31, 2013, at 9:04 AM, Stephen Lin <[hidden email]> wrote:

>> Quite the contrary, knowing that Clang's C++ ABI is completely
>> incompatible with MS is a maintenance *simplification*.
>
> Yes, for example, as explained by Bjarne once, incompatible name
> mangling schemes for ABIs that are not guaranteed to be 100% binary
> compatible is a _feature_, not a bug, since it prevents anyone from
> even beginning to develop a workflow that relies upon linking possibly
> incompatible binaries.
>
>>
>> Saying that supporting the MS C++ ABI is an uphill battle is an
>> understatement (and better say MS C++ ABI*S*, because it evolved over
>> time and it is known that it will change on future releases.) As far as
>> I'm concerned, I'll never base my decisions on compiler usage on the
>> advertisement of MS compatibility by Clang++, becase I *know* that for a
>> very long time (maybe forever) whatever MS C++ libraries that work with
>> Clang++ is by luck. That's what happens when you try to implement
>> compatibility with an undocumented, propietary, complex feature.
>
> This is my point as well; it just seems odd to spend so much effort to
> implement and undocumented ABI with no guarantee of support or
> stability (outside of MSVC major version releases). Furthermore, I
> feel that, by reinforcing the notion that use of the MSVC++ ABI is
> required for development on Windows (when no system-provided libraries
> or ABIs require it), Clang developers are hindering the adoption of
> Clang on Windows rather than promoting it, since it is unlikely that
> any party that is not personally invested in Clang development would
> be willing to depend on a backward engineered implementation of a
> "required" but undocumented ABI for production use. Furthermore, it
> means that Clang will always be behind the curve on Windows, since,
> even if MSVC++ ABI support is fully usable one day, no one will be
> willing to link it with object files from a new major version of MSVC
> without some critical mass of users being guinea pigs first and
> ensuring that there are no major bugaboos.
>
> I agree that there is value in supporting implementing full MSVC++
> ABI, if it can be done, but it seems like that support can never be
> 100% complete (or, more to the point, known to be 100% complete)
> unless Microsoft itself decides to officially support the
> implementation or completely stabilize and document their C++ ABIs.
> However, I personally think that it is not only easier, there is more
> value in implementing a C++ ABI which is compatible with officially
> supported C and COM MSVC++ ABI subsets and consciously _not_
> compatible in others way (in particular, which does not even attempt
> to link C++ symbols with MSVC++, since that is not required for COM).
> This is something that can be made to work and guaranteed (barring
> some seriously misguided behavior from Microsoft) to continue to work
> stably.
>
> Furthermore, by providing and controlling its own Windows C++ ABI:
> Clang can possibly offer something that MSVC *cannot* (and does not
> even try to do): a development platform and ecosystem which provides a
> stable-over-time C++ ABI and consistent cross-module usage of RTTI,
> STL, C++ memory management, etc. (which is dicey even within MSVC
> major versions unless the exact same build settings are used, last
> time I checked.) This would give someone an active reason to switch to
> Clang more than anything else Clang currently offers on Windows.
>
> Stephen
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Stephen Lin
Oh, well, I don't actually have any objection to the patch (I'm not
sure if Oscar does) or work in this direction. (So apologies for
hijacking, it's just I wanted to back up the sentiment that Oscar
expressed initially.)

I'm honestly just trying to understand why the engineering focus is
where it is, and wonders if anyone has put any thought into supporting
our own (or possibly someone else's, if it's documented) C++ ABI on
Windows, as a either a subgoal or parallel goal of full MSVC C++ ABI
implementation. As I said before, something like that wouldn't just be
a stop gap, it would provide real benefits on its own.

I'll stop hijacking this thread for that, though, sorry.

Stephen

On Wed, Jul 31, 2013 at 9:54 AM, Chris Lattner <[hidden email]> wrote:

> This thread is odd to me. It seems that the gist of your guys' argument is that you don't know if we will ever get full support, therefore we don't welcome progress towards that (very useful) goal/feature.
>
> If the specific proposal doesn't make make sense from a design standpoint, that's one thing, but saying we shouldn't take it because of licensing issues with MFC or because it is harmful to be partially (but not fully) compatible with MSVC seems just weird to me.
>
> -Chris
>
> On Jul 31, 2013, at 9:04 AM, Stephen Lin <[hidden email]> wrote:
>
>>> Quite the contrary, knowing that Clang's C++ ABI is completely
>>> incompatible with MS is a maintenance *simplification*.
>>
>> Yes, for example, as explained by Bjarne once, incompatible name
>> mangling schemes for ABIs that are not guaranteed to be 100% binary
>> compatible is a _feature_, not a bug, since it prevents anyone from
>> even beginning to develop a workflow that relies upon linking possibly
>> incompatible binaries.
>>
>>>
>>> Saying that supporting the MS C++ ABI is an uphill battle is an
>>> understatement (and better say MS C++ ABI*S*, because it evolved over
>>> time and it is known that it will change on future releases.) As far as
>>> I'm concerned, I'll never base my decisions on compiler usage on the
>>> advertisement of MS compatibility by Clang++, becase I *know* that for a
>>> very long time (maybe forever) whatever MS C++ libraries that work with
>>> Clang++ is by luck. That's what happens when you try to implement
>>> compatibility with an undocumented, propietary, complex feature.
>>
>> This is my point as well; it just seems odd to spend so much effort to
>> implement and undocumented ABI with no guarantee of support or
>> stability (outside of MSVC major version releases). Furthermore, I
>> feel that, by reinforcing the notion that use of the MSVC++ ABI is
>> required for development on Windows (when no system-provided libraries
>> or ABIs require it), Clang developers are hindering the adoption of
>> Clang on Windows rather than promoting it, since it is unlikely that
>> any party that is not personally invested in Clang development would
>> be willing to depend on a backward engineered implementation of a
>> "required" but undocumented ABI for production use. Furthermore, it
>> means that Clang will always be behind the curve on Windows, since,
>> even if MSVC++ ABI support is fully usable one day, no one will be
>> willing to link it with object files from a new major version of MSVC
>> without some critical mass of users being guinea pigs first and
>> ensuring that there are no major bugaboos.
>>
>> I agree that there is value in supporting implementing full MSVC++
>> ABI, if it can be done, but it seems like that support can never be
>> 100% complete (or, more to the point, known to be 100% complete)
>> unless Microsoft itself decides to officially support the
>> implementation or completely stabilize and document their C++ ABIs.
>> However, I personally think that it is not only easier, there is more
>> value in implementing a C++ ABI which is compatible with officially
>> supported C and COM MSVC++ ABI subsets and consciously _not_
>> compatible in others way (in particular, which does not even attempt
>> to link C++ symbols with MSVC++, since that is not required for COM).
>> This is something that can be made to work and guaranteed (barring
>> some seriously misguided behavior from Microsoft) to continue to work
>> stably.
>>
>> Furthermore, by providing and controlling its own Windows C++ ABI:
>> Clang can possibly offer something that MSVC *cannot* (and does not
>> even try to do): a development platform and ecosystem which provides a
>> stable-over-time C++ ABI and consistent cross-module usage of RTTI,
>> STL, C++ memory management, etc. (which is dicey even within MSVC
>> major versions unless the exact same build settings are used, last
>> time I checked.) This would give someone an active reason to switch to
>> Clang more than anything else Clang currently offers on Windows.
>>
>> Stephen
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Chandler Carruth-2


On Jul 31, 2013 10:16 AM, "Stephen Lin" <[hidden email]> wrote:
>
> Oh, well, I don't actually have any objection to the patch (I'm not
> sure if Oscar does) or work in this direction. (So apologies for
> hijacking, it's just I wanted to back up the sentiment that Oscar
> expressed initially.)
>
> I'm honestly just trying to understand why the engineering focus is
> where it is, and wonders if anyone has put any thought into supporting
> our own (or possibly someone else's, if it's documented) C++ ABI on
> Windows, as a either a subgoal or parallel goal of full MSVC C++ ABI
> implementation. As I said before, something like that wouldn't just be
> a stop gap, it would provide real benefits on its own.

Thia patch and the others currently under development seem clearly aimed at compatibility
If you or others are interested in something else then mail the patches. I don't think any of this precludes the other.

>
> I'll stop hijacking this thread for that, though, sorry.

If you're around I think several of us will be at the social tomorrow. Always a good place to have such discussions.

>
> Stephen
>
> On Wed, Jul 31, 2013 at 9:54 AM, Chris Lattner <[hidden email]> wrote:
> > This thread is odd to me. It seems that the gist of your guys' argument is that you don't know if we will ever get full support, therefore we don't welcome progress towards that (very useful) goal/feature.
> >
> > If the specific proposal doesn't make make sense from a design standpoint, that's one thing, but saying we shouldn't take it because of licensing issues with MFC or because it is harmful to be partially (but not fully) compatible with MSVC seems just weird to me.
> >
> > -Chris
> >
> > On Jul 31, 2013, at 9:04 AM, Stephen Lin <[hidden email]> wrote:
> >
> >>> Quite the contrary, knowing that Clang's C++ ABI is completely
> >>> incompatible with MS is a maintenance *simplification*.
> >>
> >> Yes, for example, as explained by Bjarne once, incompatible name
> >> mangling schemes for ABIs that are not guaranteed to be 100% binary
> >> compatible is a _feature_, not a bug, since it prevents anyone from
> >> even beginning to develop a workflow that relies upon linking possibly
> >> incompatible binaries.
> >>
> >>>
> >>> Saying that supporting the MS C++ ABI is an uphill battle is an
> >>> understatement (and better say MS C++ ABI*S*, because it evolved over
> >>> time and it is known that it will change on future releases.) As far as
> >>> I'm concerned, I'll never base my decisions on compiler usage on the
> >>> advertisement of MS compatibility by Clang++, becase I *know* that for a
> >>> very long time (maybe forever) whatever MS C++ libraries that work with
> >>> Clang++ is by luck. That's what happens when you try to implement
> >>> compatibility with an undocumented, propietary, complex feature.
> >>
> >> This is my point as well; it just seems odd to spend so much effort to
> >> implement and undocumented ABI with no guarantee of support or
> >> stability (outside of MSVC major version releases). Furthermore, I
> >> feel that, by reinforcing the notion that use of the MSVC++ ABI is
> >> required for development on Windows (when no system-provided libraries
> >> or ABIs require it), Clang developers are hindering the adoption of
> >> Clang on Windows rather than promoting it, since it is unlikely that
> >> any party that is not personally invested in Clang development would
> >> be willing to depend on a backward engineered implementation of a
> >> "required" but undocumented ABI for production use. Furthermore, it
> >> means that Clang will always be behind the curve on Windows, since,
> >> even if MSVC++ ABI support is fully usable one day, no one will be
> >> willing to link it with object files from a new major version of MSVC
> >> without some critical mass of users being guinea pigs first and
> >> ensuring that there are no major bugaboos.
> >>
> >> I agree that there is value in supporting implementing full MSVC++
> >> ABI, if it can be done, but it seems like that support can never be
> >> 100% complete (or, more to the point, known to be 100% complete)
> >> unless Microsoft itself decides to officially support the
> >> implementation or completely stabilize and document their C++ ABIs.
> >> However, I personally think that it is not only easier, there is more
> >> value in implementing a C++ ABI which is compatible with officially
> >> supported C and COM MSVC++ ABI subsets and consciously _not_
> >> compatible in others way (in particular, which does not even attempt
> >> to link C++ symbols with MSVC++, since that is not required for COM).
> >> This is something that can be made to work and guaranteed (barring
> >> some seriously misguided behavior from Microsoft) to continue to work
> >> stably.
> >>
> >> Furthermore, by providing and controlling its own Windows C++ ABI:
> >> Clang can possibly offer something that MSVC *cannot* (and does not
> >> even try to do): a development platform and ecosystem which provides a
> >> stable-over-time C++ ABI and consistent cross-module usage of RTTI,
> >> STL, C++ memory management, etc. (which is dicey even within MSVC
> >> major versions unless the exact same build settings are used, last
> >> time I checked.) This would give someone an active reason to switch to
> >> Clang more than anything else Clang currently offers on Windows.
> >>
> >> Stephen
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> [hidden email]         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Reid Kleckner-2
On Wed, Jul 31, 2013 at 10:33 AM, Chandler Carruth <[hidden email]> wrote:


On Jul 31, 2013 10:16 AM, "Stephen Lin" <[hidden email]> wrote:
>
> Oh, well, I don't actually have any objection to the patch (I'm not
> sure if Oscar does) or work in this direction. (So apologies for
> hijacking, it's just I wanted to back up the sentiment that Oscar
> expressed initially.)
>
> I'm honestly just trying to understand why the engineering focus is
> where it is, and wonders if anyone has put any thought into supporting
> our own (or possibly someone else's, if it's documented) C++ ABI on
> Windows, as a either a subgoal or parallel goal of full MSVC C++ ABI
> implementation. As I said before, something like that wouldn't just be
> a stop gap, it would provide real benefits on its own.

Thia patch and the others currently under development seem clearly aimed at compatibility
If you or others are interested in something else then mail the patches. I don't think any of this precludes the other.

Just to clarify, there's no patch for this particular issue yet.  This is an RFC so I don't waste time on patches that will be rejected due to high level concerns.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
12