[PATCH] First set of patches for type uniquing

Manman Ren manman.ren at gmail.com
Mon Aug 26 16:18:03 PDT 2013


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?
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).


> 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.

Thanks,
Manman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130826/627e62ca/attachment.html>


More information about the llvm-commits mailing list