[PATCH] Option to suppress the DWARF entries DW_AT_MIPS_linkage_name and DW_AT_linkage_name.

[Robinson, Paul]

> -----Original Message-----
> From: Eric Christopher [mailto:echristo at gmail.com]
> Sent: Friday, September 26, 2014 3:32 PM
> To: Robinson, Paul
> Cc: reviews+D5510+public+1bd74400151549c7 at reviews.llvm.org; Pieb,
> Wolfgang; llvm-commits at cs.uiuc.edu
> Subject: Re: [PATCH] Option to suppress the DWARF entries
> DW_AT_MIPS_linkage_name and DW_AT_linkage_name.
> 
> On Fri, Sep 26, 2014 at 3:23 PM, Robinson, Paul
> <Paul_Robinson at playstation.sony.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> >> bounces at cs.uiuc.edu] On Behalf Of Eric Christopher
> >> Sent: Friday, September 26, 2014 3:09 PM
> >> To: Pieb, Wolfgang
> >> Cc: llvm-commits at cs.uiuc.edu
> >> Subject: Re: [PATCH] Option to suppress the DWARF entries
> >> DW_AT_MIPS_linkage_name and DW_AT_linkage_name.
> >>
> >> ================
> >> Comment at: lib/CodeGen/AsmPrinter/DwarfUnit.cpp:45
> >> @@ +44,3 @@
> >> +static cl::opt<bool>
> >> +SuppressLinkageNames("suppress-dwarf-linkage-names", cl::Hidden,
> >> +                     cl::desc("Suppress the DWARF
> >> DW_AT_(MIPS_)?linkage_name entries"),
> >> ----------------
> >> dblaikie wrote:
> >> > I believe we're trying to move away from surfacing command line flags
> in
> >> this way for user-facing features. (see Chris Bieneman's work).
> >> >
> >> > I'm not sure what the right answner is these days - this could be a
> flag
> >> on the compile_unit metadata - in which case it could be properly
> >> respected under LTO (if one CU was built with the flag and one built
> >> without it, it'd be possible/practical/easy to respect those
> differences,
> >> emitting linkage name for one CU and omitting it in another).
> >> It's definitely a code gen option and so should go on a code gen option
> >> struct. That said, we're probably getting enough of them that a sub
> struct
> >> for debug info would be better.
> >>
> >> i.e. I don't see why we'd want to handle adding or subtracting on a CU
> >> basis and thus need to put it on the metadata.
> >
> > Per-CU is not important. Working with LTO is important. I didn't think
> the
> > codegen options showed up in the IR/metadata? Happy to be wrong there.
> 
> You're wrong. :)

Woohoo!

> 
> Anything that's function dependent will show up on a function.
> Anything CU dependent should show up on a CU in the metadata.
> 
> That said, this is likely a whole module (or post-link module in the
> case of LTO) code generation time option and should show up
> accordingly.

Hmmm getting into terra incognita here, AFAICT this is all sort of ad-hoc.
What might be a useful model here?  CGM's EmitModuleLinkOptions, perhaps?
Or CGM's EmitTargetMetadata?  Something else?
Thanks,
--paulr

> 
> -eric
> 
> > --paulr
> >
> >>
> >> http://reviews.llvm.org/D5510
> >>
> >>
> >>
> >> _______________________________________________
> >> llvm-commits mailing list
> >> llvm-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits