[llvm] r214111 - [Debug Info] replace DIUnspecifiedParameter with DITrivialType.

[Manman Ren]

In r214189, r214190.

Thanks,
Manman


On Mon, Jul 28, 2014 at 5:34 PM, Eric Christopher <echristo at gmail.com>
wrote:

> >>
> >> Yes, it is mainly for size reasons. But you are right, we will only
> have one
> >> unspecified_type and one unspecified_parameter for each module.
> >> The other reason is for clarity so we know these two are trivial types
> >> without size, offset etc.
> >>
> >> I am okay with removing DITrivialType if it is a burden to have one more
> >> class in our DIType hierarchy.
> >
> > It really is a bit awkward to derive here - since unspecified type has
> > strictly /less/ functionality (hence all the assertions that were
> > added) - it should be further up the inheritance hierarchy, if
> > anywhere. And it's not /exactly/ a type, though it's convenient to
> > treat it as one.
> >
> > We could be hackish in a different way, and treat null in the
> > subroutine type list as being "unspecified type" (null in the first
> > slot means "void return", but null in later (and only trailing)
> > positions in the array could be "unspecified parameters")
> >
> > The "right" thing would be for there to be a type from which DIType
> > would derive (call it, say, DIThingsInSubroutineTypes) that we either
> > used directly, or had a separate derived type for
> > DIUnspecifiedParameters - that type (DIThingsInSubroutineTypes)
> > wouldn't have any of the member functions DIType has, because it
> > doesn't have any data/features.
> >
> > But then we'd need DIThingsInSubroutineTypesRef as well, etc, etc...
> >
> > I'm sort of inclined to use null here. Eric - what do you reckon?
> >
> > {null} -> "void()"
> > {null, null} -> "void(...)"
> > {null, <metadata node for int>, null} -> "void(int, ...)"
> > {null, null, <metadata node for int>} -> invalid
> >
> > Eric - what do you reckon?
>
> Seems reasonable.
>
> -eric
>
> >
> > Easy to implement, just have createUnspecifiedParameter return null,
> > and have the two places that check for isUnspecifiedParameter check
> > for null instead.
> >
> > Any other reasons we'd have null in a parameter type list?
> >
> > But, yeah, alternatively we just use a basic DIType and don't worry
> > about the rest of the fields - it's a bit trickier I think (having a
> > non-null DIType object with a bunch of operations that are invalid -
> > null/non-nullness is a bit more of a clearer distinction - either
> > you've got all the operations or none of them).
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140729/7f787be8/attachment.html>