[PATCH] D43002: Emit S_OBJNAME symbol in CodeView

[David Blaikie via llvm-commits]

On Wed, Feb 7, 2018 at 10:28 AM Zachary Turner via Phabricator <
reviews at reviews.llvm.org> wrote:

> zturner added a comment.
>
> In https://reviews.llvm.org/D43002#1000801, @dblaikie wrote:
>
> > > It would be more efficient to put, e.g., a NamedMDNode into the module
> so this information can be shared between the CUs.
> >
> > I assume the string data itself is shared by the bitcode format? But I
> don't really know.
>
>
> All of this code is new to me, so I'm still kind of fumbling along as I
> learn how all this stuff works together,


Yeah, that question was more directed at Adrian.


> but my impression was that Adrian's suggestion only really applied if I
> wanted the name of the lto.o file.  Given that I need the name of the
> bitcode containing .o file, does any of this still apply?  Is the current
> solution appropriate in that case?
>

Yeah, this issue still applies somewhat - Adrian mentioned the case of
Swift producing multiple CUs even for a single swift file/object file. So
arguably if the string data in each CU was stored separately, there might
be some benefit to be gained by figuring out a way to share it between
those CUs.


>
>
>
> ================
> Comment at: llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp:674-679
> +  for (unsigned i = 0; i != Str.size(); ++i) {
> +    if (Str[i] == '\\' && i != Str.size() - 1) {
> +      if (Str[i + 1] == '\\')
> +        Str.erase(Str.begin() + i + 1);
> +    }
> +  }
> ----------------
> dblaikie wrote:
> > This is O(N^2) (erase is O(N)) & could be made O(N) (using a technique
> similar to the erase+remove idiom - using literal erase+remove probably
> isn't practical due to the stateful nature of the walk).
> >
> > Is there no other logic for this already elsewhere in LLVM?
> Unfortunately there's not.  But you're right, I can do this a bit more
> efficiently by keeping a separate read pointer and write pointer.
>
>
> https://reviews.llvm.org/D43002
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180207/24fa4a20/attachment.html>