[cfe-commits] [PATCH] Laying the foundation for alternate C++ ABI support

[Douglas Gregor]

On May 25, 2010, at 1:33 PM, John McCall wrote:

> 
> On May 25, 2010, at 12:56 PM, Douglas Gregor wrote:
> 
>> 
>> On May 25, 2010, at 12:54 PM, Charles Davis wrote:
>> 
>>> On 5/25/10 11:18 AM, John McCall wrote:
>>>> On May 24, 2010, at 10:43 PM, Charles Davis wrote:
>>>>> This is the first patch in my GSoC series, in which I will factor out
>>>>> C++ ABI support in IRgen so that we can support other C++ ABIs. This
>>>>> patch is very simple. It just adds a class hierarchy similar to the one
>>>>> for Objective-C runtimes, and a basic implementation for the current GNU
>>>>> C++ ABI. All it supports is name mangling. CodeGenFunction has been
>>>>> redirected to use this new interface instead of holding the
>>>>> MangleContext itself (which is very specific to the GNU ABI right now).
>>>> 
>>>> For better or worse, people call this the Itanium ABI;  gcc's implementation hews
>>>> faithfully to that standard, and we should use that name.  The term "GNU ABI" is likely
>>>> to make people think of the old (pre-v3.2) gcc ABI.
>>> Noted.
>>>> 
>>>> Also, I think we can live without the "CG" prefix on "CGCXXABI".
>>> Done. (The header name still has the CG prefix, though.)
>>>> 
>>>> I'd prefer to avoid lazy initialization.  We should never be calling into the
>>>> CXXABI for non-C++ code, so you should be able to create it during initialization
>>>> if CPlusPlus is set and then assert on its existence in getCXXABI().
>>> I don't know about that.
>>> 
>>> When I added the assert, clang started asserting whenever it was
>>> generating IR for non-C++ (that's C and ObjC) code. I think clang right
>>> now just assumes that the MangleContext is always available and will "Do
>>> the Right Thing" based on whether or not Features.CPlusPlus is set.
>>> 
>>> I agree, C and ObjC IRgen shouldn't be calling into any C++-specific
>>> stuff. But I'll fix that later.
>> 
>> 
>> We use the "C++" mangler for some things in C/Objective-C as well, including blocks (a recent change), overloaded functions in C, and (IIRC) some Objective-C method names.
> 
> Ah, right, I'd forgotten about that.  So yeah, we should continue to lazily create the C++ ABI.
> 
> I suppose it's reasonable to always defer these manglings to the target C++ ABI.  Maybe we can abstract out some common functionality so that new ABIs don't need so many redundant manglings.

Yes, I think that makes sense. Separating ObjC from C++ might be reasonable, for example.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100525/782c8c05/attachment.html>