[PATCH] First set of patches for type uniquing

Eli Friedman eli.friedman at gmail.com
Fri Aug 2 19:59:22 PDT 2013


On Fri, Aug 2, 2013 at 6:16 PM, Manman Ren <manman.ren at gmail.com> wrote:
> On 8/2/13, 4:31 PM, Eli Friedman wrote:
>>
>> On Wed, Jul 31, 2013 at 4:37 PM, Manman Ren <manman.ren at gmail.com> wrote:
>>>
>>> After cleaning up usage of the verify function and all the testing cases,
>>> the first set of patches are ready for review :)
>>>
>>> 3 patches are included: one for clang (tu_clang_07312013.patch), one for
>>> code change of llvm (tu_07312013.patch), and one for updating all the
>>> testing cases (tu_test_07312013.patch).
>>>
>>> The following are implemented:
>>> 1> DIType will have a unique name at field 9.
>>>       For DIBasicType, DICompositeType, DIDerivedType, the fields after
>>> will
>>> be shifted by 1.
>>> 2> I am going to update usage of DIType in phases:
>>>       At the first batch, getContainingType of DICompositeType and
>>> DISubprogram will be replaced with a MDString, as well as getClassType of
>>> DIDerivedType.
>>> 3> The verifier is updated according to 1 and 2.
>>> 4> DwarfDebug has a TypeMap.
>>>        It also has a helper function lookupType to find the corresponding
>>> DIType given a type name.
>>> 5> how to generate the unique name?
>>>        The clang frontend has two helper functions: getUniqueTagTypeName
>>> and
>>> getUniqueTypeName
>>>            The first one handles TagType and it uses ODR (One Definition
>>> Rule) for external c++ types. It is currently called for struct, class,
>>> union and enum.
>>>            The second one can be used for general types, it uses mangled
>>> name
>>> appended with CU's directory and file name to provide uniqueness across
>>> CUs.
>>> It is currently used to generate unique name for subroutine type. For
>>> other
>>> types, DIBuilder will provide a unique name. Clang can handle more types
>>> in
>>> follow-on patches if it can provide a better name than DIBuilder.
>>>        DIBuilder also has a helper function getUniqueTypeName, this is
>>> called
>>> when consumer of DIBuilder does not provide a unique type name. This is
>>> needed for dragonegg, before it provides a unique name (not sure whether
>>> it
>>> is needed).
>>> 6> All DITypes created by DIBuilder will be added to RetainTypes.
>>>
>>> Comments and feedback are welcome.
>>
>> Comments on the clang side:
>>
>> Please don't call mangleCXXRTTIName outside of C++.  Also, please use
>> getLangOpts().CPlusPlus to check whether we are in C++.
>
> Thanks for the comments.
>
> Yes, I should check the language first before calling mangleCXXRTTIName and
> will use DIBuilder to provide a unique
> name for other languages.
>
> Language tag of the CompileUnit is set to C_plus_plus when
> getLangOpts().CPlusPlus and
> !getLangOpts().Objc1. I choose to turn on ODR only for C++
> (TheCU.getLanguage() == DW_LANG_C_plus_plus),
> not ObjC++, since I am not sure about the existence of a standard about ODR
> for ObjC++.

If that's what you mean, please write it explicitly.  That said, I
don't think you'll run into any issues; ODR applies to ObjC++ exactly
the same way it does to C++.

-Eli



More information about the llvm-commits mailing list