This is an archive of the discontinued LLVM Phabricator instance.

Move Microsoft Demangler to Support
Needs ReviewPublic

Authored by zturner on Aug 23 2018, 10:42 AM.

Details

Summary

It seems like people feel that Demangler logically belongs in Support *anyway*, but for logistical reasons (such as libcxxabi needing to use the itanium demangler), it can't yet go there.

The Microsoft demangler doesn't have the same restrictions, and doesn't make sense to ever be part of libcxxabi either. So while it's nice from a layering perspective to put all demanglers the same place, it comes with the downside of impeding the development and making the code worse.

The MS Demangler is mostly complete, but I'd like to take some time to make it not just work, but also be clean. Having access to some Support classes (Casting.h, StringRef.h, SmallVector.h, raw_ostream.h, etc) would really help clean up a lot of the code (as well as making it more efficient in some cases).

Currently there's no use case for a standalone Microsoft demangler, and supporting standalone versions of all of the various things LLVM can do seems like a non-goal anyway so I think this is a win.

Diff Detail

Event Timeline

zturner created this revision.Aug 23 2018, 10:42 AM
rnk added a comment.Aug 23 2018, 10:44 AM

Won't this make tablegen rebuild every time you change the demangler? Is that really necessary?

In D51174#1211241, @rnk wrote:

Won't this make tablegen rebuild every time you change the demangler? Is that really necessary?

Sure, but that's kind of the cost of doing business with our monolithic approach to Support. I've been making changes to Demangler a lot recently, but eventually it should get to the point where people rarely change anything.

rnk added a comment.Aug 23 2018, 10:47 AM
In D51174#1211241, @rnk wrote:

Won't this make tablegen rebuild every time you change the demangler? Is that really necessary?

I guess that's not a concern. I forgot I had to go look in LLVMBuild.txt to see an LLVM libraries dependencies, not CMakeLists.txt like usual. =p

rnk added a comment.Aug 23 2018, 10:52 AM

I guess I don't like this change because it makes our demanglers, which should ideally be super standalone, no STL usage code, more entangled with the rest of LLVM. It would be nice if, for example, we could compile this code into sanitizer libraries. Today we have a solution (llvm-symbolizer) that essentially pushes the symbolization work out of process into LLVM code, but you can imagine wanting to have a complete in-library solution.

In D51174#1211249, @rnk wrote:

I guess I don't like this change because it makes our demanglers, which should ideally be super standalone, no STL usage code, more entangled with the rest of LLVM. It would be nice if, for example, we could compile this code into sanitizer libraries. Today we have a solution (llvm-symbolizer) that essentially pushes the symbolization work out of process into LLVM code, but you can imagine wanting to have a complete in-library solution.

I don't know, we don't have these restrictions anywhere else in LLVM. Lots of things would be nice I guess, but unless anyone needs it today, I'd prefer to go with YAGNI and if we ever do, then we can do something like what Richard did with the Itanium demangler.

thakis added a subscriber: thakis.Aug 23 2018, 5:32 PM

FWIW I'd like to use the new demangler in demumble [1], but if I need to pull in most of Support of it then I probably won't do that. I agree this shouldn't impact LLVM much (or at all), but having stand-alone-ish demangler code is probably nice for several other projects too. So since the itanium demangler is still in the other place and likely will stay there, maybe it's nice to keep the ms demangler next to it. (But as I said, don't weigh this feedback heavily.)

1: https://github.com/nico/demumble

What if we produced a .lib file that had only the minimal set of object
files needed to link this, and make MicrosoftDemangle.h not include other
llvm headers, then you could just link against that object file and it
should be effectively independent.

Would that work?

What if we produced a .lib file that had only the minimal set of object
files needed to link this, and make MicrosoftDemangle.h not include other
llvm headers, then you could just link against that object file and it
should be effectively independent.

Would that work?

I copy over the source files I need, so .lib files wouldn't help me. Right now, it's "copy 1 file" and it's fairly easy to rev. It'd become "figure out subset of Support currently needed", which will likely be different each time. Keeping things in their own project does keep this more manageable (which is why this how it's done for the itanium mangler).

smeenai resigned from this revision.Apr 28 2022, 2:08 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 28 2022, 2:08 PM
Herald added a subscriber: dexonsmith. · View Herald Transcript