[PATCH] D55281: debuginfo: Use symbol difference for CU length to simplify assembly reading/editing

Mon Dec 17 14:31:11 PST 2018

ABataev added a comment.

In D55281#1333552 <https://reviews.llvm.org/D55281#1333552>, @dblaikie wrote:

> In D55281#1333515 <https://reviews.llvm.org/D55281#1333515>, @ABataev wrote:
>
> > In D55281#1333514 <https://reviews.llvm.org/D55281#1333514>, @dblaikie wrote:
> >
> > > >> But I'm still confused & would love some help understanding why/how some of these features are gated by the cl::opt -dwarf-sections-as-references or NVPTX - but other features are gated only on NVPTX? Should we remove -dwarf-sections-as-references and just rely on NVPTX for all these things? Or is there some other use of -dwarf-sections-as-references that isn't NVPTX?
> > > > 
> > > > Because we don't want to rely on a particular target type. Yes, currently it is used only for NVPTX. But later there might be some other targets with the same limitation and we can reuse the same option for all such targets.
> > >
> > > But all the other things (ranges, inline strings, loc, etc) are predicated based on NVPTX directly, right? Seeing one part of it separated out as a flag makes me think that there are other users of that flag - but if they're all equally requirements/limitations of ptxas, seems to me they should be predicated/treated the same way (& if we had another user that ends up needing some of this, we could refactor that out/flag it at that point - and then the difference between the handling would be explained by the difference in the needs of the current NVPTX situation and whatever the new thing is?)
> >
> >
> > No, most of them are also controlled by the options like `-dwarf-inlined-strings` for inlined strings. They are just forced to et to `true` by default for NVPTX.
>
>
> Fair enough - though I'm not really sure of the value of all the flags.
>
> @aprantl @probinson - you folks haev any feelings about this? Looks like these flags are essentially unused (except for testing, which could equally be accomplished by tests that specify an NVPTX triple, I think (except on builds that aren't building an NVPTX backend)) & are a collection of features that are all only needed on NVPTX. I'd lean towards removing them all & gating this on NVPTX. Or on one flag rather than several fine-grained ones, if/when someone starts playing with a ptx assembler that can cope with these features.
>
> But yeah, no big deal I guess - leads to a bit of confusion about who these flags are meant for, under what conditions some of these features might be enabled but not others, etc.

David, all the patches that introduced those options were reviewed and accepted by Eric Christopher.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55281/new/

https://reviews.llvm.org/D55281