[PATCH] D15996: Avoid undefined behavior in LinkAllPasses.h

[Dimitry Andric via llvm-commits]

The code is live, because a ForcePassLinking global object is created, and its constructor calls all these functions.  I don't think even LTO can eliminate global objects?

This construction was originally added a long time ago, in r19307 <http://llvm.org/viewvc/llvm-project?view=revision&revision=19307>, with an explanatory comment: "This header file is required for building with Microsoft's VC++, as it has no way of linking all registered passes into executables other than by explicit use".  A similar header for analysis passes was added by Chris in r23921 <http://llvm.org/viewvc/llvm-project?view=revision&revision=23921>, and later merged into LinkAllPasses.h by Reid in r29787 <http://llvm.org/viewvc/llvm-project?view=revision&revision=29787>.

The goal is evidently to prevent LTO from optimizing away passes.  Apparently the passes are constructed in such a way that their data or functions are not always referenced, but they can still be used?  Some passes have comment similar to:

// Create methods available outside of this file, to use them
// "include/llvm/LinkAllPasses.h". Otherwise the pass would be deleted by
// the link time optimization.

namespace llvm {
  FunctionPass *createMachineRegionInfoPass() {
    return new MachineRegionInfoPass();
  }
}

I think the passes may try to avoid having any global constructors, and therefore there may be a risk of LTO optimizing them away...

-Dimitry

> On 12 Jan 2016, at 17:50, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Tue, Jan 12, 2016 at 8:41 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
> You need to be careful that an LTO build won’t inline and eliminate this.
> 
> fair - but these calls, if they'd executed, would've been totally bogus, right? (they would've crashed/null dereferenced, etc)
> 
> So somehow this code is live without it actually executing.
> 
> To come back to the underlying issue: What is it we're trying to solve here? What entities are we trying to preserve & why are more traditional/normal ways of preserving them insufficient? (sorry if this is too much of a derailment/the rest  of you have enough context here, feel free to go on without me ;))
> 
> 
> —
> Mehdi
> 
>> On Jan 12, 2016, at 8:02 AM, David Blaikie via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>> 
>> Do you need to call anything? Could you just take the address of the function and return it, stuff it in a global, or otherwise escape it?
>> 
>> On Tue, Jan 12, 2016 at 12:02 AM, Dimitry Andric via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>> dim added a subscriber: grosser.
>> 
>> ================
>> Comment at: include/llvm/LinkAllPasses.h:191
>> @@ -190,3 +196,3 @@
>>        llvm::RGPassManager RGM;
>> -      ((llvm::RegionPass*)nullptr)->runOnRegion((llvm::Region*)nullptr, RGM);
>>        llvm::AliasSetTracker X(*(llvm::AliasAnalysis*)nullptr);
>> ----------------
>> @grosser, you originally added this part in rL117263 ("Reference RegionPass to stop it being eliminated"), do you have any suggestions? If the goal is to to unsure RegionPass.cpp is linked in, I think we can call `RegionPass::createPrinterPass()` instead.
>> 
>> 
>> http://reviews.llvm.org/D15996 <http://reviews.llvm.org/D15996>
>> 
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160112/e5214324/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160112/e5214324/attachment.sig>