[cfe-dev] [llvm-dev] RFC: Up front type information generation in clang and llvm

[Reid Kleckner via cfe-dev]

Responses to Mehdi and Eric below.

On Wed, Apr 27, 2016 at 4:53 PM, Eric Christopher <echristo at gmail.com> wrote:
> I don't agree in general here because of:
>
> a) maintainability - there isn't a one true path through things and now is
> scattering more windows knowledge through debug info and lto

There was never going to be one true way to generate LLVM debug info
for both formats. We need some help from the frontend.

> b) higher bar for implementing similar dwarf functionality - there's nothing
> here that makes it at any point better for our general debug info support.
> Incrementally updating to an intermediate step is much easier and a lower
> bar than needing to implement everything up to and including a format aware
> linker and support that through ThinLTO, the JIT, and full LTO.

I claim that everything does not have to be format aware. All it has
to do is call out to a library which is format aware. We can come up
with reasonable high-level abstractions for operations that we'll want
to do on types, such as "extract this type and everything it
references".

> c) if there's no reason to do this for dwarf there's no reason to do it for
> windows. The existing proposal was a way to get you type emission in the
> front end so that you'd have to do less work. Ultimately though I don't see
> a reason to do this if all of the platforms don't look the same.

There are reasons to do this for DWARF, but they are not compelling
enough to do a total rewrite of our type information support.

> d) ThinLTO/ORC won't support the debug info you have in your proposal right
> now without patches
>
> e) You're regressing LTO linking performance hugely for windows with debug
> until you write the patches that enable format aware linking of code view
> information

The way I see it, there is no existing CodeView debug info
functionality to regress for any of ORC, LTO, or ThinLTO. Apparently
we don't see this the same way.

And I've already written the patch to do type merging:
http://reviews.llvm.org/D20122 Regular LTO can call this code, and
rewrite the DITypeIndex numbers with the map produced. While this may
not be directly applicable to ORC and ThinLTO, I don't expect that
supporting them will be much more work.



On Tue, May 10, 2016 at 11:32 PM, Mehdi Amini via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> On the other hand, it seems that what you're proposing is basically
> "optimized" for "type units" (which are not supported on Darwin anyway) and
> the only advantage we could see is to have an easy way of type-uniquing
> directly in the IR.

Splitting up the type information into opaque units lets you do
format-agnostic type uniquing, but it doesn't let you extract forward
declarations like ThinLTO wants to do.

> Our conclusion was that for us, a single type blob with somehow "smart
> reference" to be able to point inside the blob from the outside is the most
> efficient things we can built upon. However the cost/benefit of getting
> there is too high for us to prioritize working this at this point.
> (If I misrepresented anything, please Adrian/Duncan/Fred correct me)

Yeah, this is kind of where I am. Having one blob per module is
probably the most efficient thing possible that I could do for
CodeView, but I estimate that the cost of also doing it for DWARF is
very high. We have a lot of dependencies on the existing
representation. We can attempt to try and generalize up-front emission
to DWARF, but I think if we don't pay the full cost, we will end up
with something half-baked for DWARF. I don't think I have the time to
do it justice.

Speaking of the idea of smart references that point out of the IR into
separate type info, my current approach (DITypeIndex) is very
CV-specific. However, I think if we allow one kind of smart reference,
we can add support for more, and they can be format-specific. As long
as we're OK making DITypeRefs opaque, adding new kinds of type refs is
cheap.