[PATCH] D20083: Add an c++ itanium demangler to llvm

Duncan P. N. Exon Smith via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 24 13:04:39 PDT 2016


> On 2016-Aug-24, at 11:24, Craig, Ben <ben.craig at codeaurora.org> wrote:
> 
> On 8/24/2016 1:20 PM, Rafael Espíndola wrote:
>> We need a demangler in llvm, and that requires annoying tradeoffs:
>> 
>> * llvm depends on libc++abi.
>> * libc++abi depends on llvm.
>> * both llvm and libc++abi dependent on a libdemangle.
>> * we keep a file in both repositories.
>> * we have two independent implementations.
>> 
>> The first 3 introduce annoying dependencies. The last one means the llvm demangler can have a nice interface (stringref), but duplicates a lot of code.
>> 
>> Having a file that is copied in both repositories is the least horrible option IMHO. Having said that, any solution where lld on windows can demangle itanium  names would work for us.
>> 
> I agree that duplication isn't ideal.  I also agree that it's probably the best option here.  I think option 4 naturally turns into option 5 over time, and in this situation, I think that is also fine (though annoying).

Also:
* Split out lib/Support (or a subset); llvm and libc++abi depend on a libdemangle

This would be pretty annoying right now, but straightforward in a "monorepo" world.  I think it's the right long term goal.

In the short term, a file in two repositories (option #4) seems pragmatic to me.

> 
>> Cheers,
>> Rafael
>> 
>> 
>> On Aug 24, 2016 1:16 PM, "Mehdi Amini" <mehdi.amini at apple.com> wrote:
>> 
>> > On Aug 24, 2016, at 9:56 AM, Craig, Ben <ben.craig at codeaurora.org> wrote:
>> >
>> > On 8/24/2016 11:31 AM, Rafael Espíndola wrote:
>> >>> 1. I think there are already too many build time dependencies crossing the compiler / runtime boundary.  I'm tired of my libcxx and libcxxabi builds failing because of unrelated cmake changes in LLVM.  To avoid that, I could build a standalone version... but now that won't be easily possible because of this change.
>> >> Not sure I follow. Note that this function is in an independent
>> >> library with no dependencies.
>> >>
>> >>> Building libcxx and libcxxabi shouldn't require me to pull down llvm sources, or to have a "dev" install of llvm, and this change makes that problem even worse than it already is.  Will this even work for the cross compilation cases?
>> >> This should not change this case at all. This just adds a file to llvm
>> >> itself. In a future change I will add a ifdef to it so that it can
>> >> also be used with no changes in libcxxabi.
>> > I guess I'm protesting the future change, rather than this change. libc++abi should not use source files, header files, static libraries, or shared objects that come from the llvm repository.
>> 
>> That's bothering: it means that any functionality has to be reimplemented (can’t use simple StringRef or Twine helper, which is annoying when doing string processing like here).
>> 
>>>> Mehdi
>> 
> 
> -- 
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
> 



More information about the llvm-commits mailing list