[PATCH] First set of patches for type uniquing

[David Blaikie]

On Mon, Aug 26, 2013 at 4:18 PM, Manman Ren <manman.ren at gmail.com> wrote:
>
>
>
> On Mon, Aug 26, 2013 at 4:00 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> On Mon, Aug 26, 2013 at 3:46 PM, Manman Ren <manman.ren at gmail.com> wrote:
>> > In r189282 and r189283.
>> >
>> > I will work on clang front-end to generate the unique identifier for
>> > DICompositeType.
>>
>> For each field that uses a DIType that may refer to a DICompositeType,
>> we'll see two patches - one for the backend support (to do the
>> necessary indirect access through a map lookup) and frontend support
>> to emit a name.
>
>
> By frontend support, are you referring to the change to DIBuilder?

I was thinking of the actual bit where Clang passes in an identifier,
but yes - that'll be fairly mechanical (lots of test cases to update)
& a no-op until DIBuilder actually propagates that to type references.

> DIBuilder
> will
> inspect the DIType reference, and if it is a DICompositeType and the unique
> identifier is non-null, DIBuilder will use the identifier instead of the
> MDNode itself.
>
> Per our discussion via IRC, I thought clang will first generate unique
> identifier for
> external C++ DICompositeTypes. The next step is to update the usage of a
> DIType
> that may refer to a DICompositeType (with one use as a start).

You're right, this could happen in either order & either will be
testable but have no ultimate effect until both frontend and backend
have been modified.

So I suppose to get my "one simple case" working, we'd be talking
about having DIBuilder do the "is this a DICompositeType, if so use
the identifier instead of the MDNode" check on exactly one field &
implement the backend support for that too.

>
>>
>> The backend patch can be committed prior to the
>> frontend patch (though the frontend patch would be a nice way to
>> generate the backend test to ensure it's what we intend to
>> support/works end-to-end).
>>
>> It'd be good to see exactly one (a small one, where possible) use of
>> this first so we can checkin the map creation & lookup plumbing with a
>> single simple field to motivate/demonstrate/test it, then
>> incrementally commit support for each field after that.
>
> Agreed.

OK, so:

1) add identifier from Clang (DIBuilder support, plus passing in the
identifier from Clang), updating lots of Clang test cases
2) add LLVM support for mapping one particular type field, if it's
string instead of an MDNode, add explicit test cases, possibly
generated by Clang with (2.1)
2.1) (can be separate from (2), probably should be for reviewability -
that does leave (2) semi-untested - a manual test case or test case
generated with (2.1) but committed with (2) might be OK) change
DIBuilder to do the string-instead-of-mdnode thing for that one field.

(2.1 can't come before 2 or Clang would be broken in the interim -
generating identifier references when LLVM was incapable of doing the
mapping)

Repeat 2 and 2.1 for one field at a time until done.