[PATCH] First set of patches for type uniquing

Manman Ren manman.ren at gmail.com
Mon Aug 12 10:23:03 PDT 2013


Hi Eric,

Did you get a chance to review the patch?

Thanks,
Manman

On 8/6/13, 3:59 PM, Eric Christopher wrote:
> I'll get to reviewing this as I can.
>
> -eric
>
> On Tue, Aug 6, 2013 at 10:58 AM, Manman Ren <manman.ren at gmail.com> wrote:
>> Updated the clang patch to address Eli's comments.
>>
>> Thanks,
>> Manman
>>
>>
>> On 8/2/13, 7:59 PM, Eli Friedman wrote:
>>> 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