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

[Dimitry Andric via llvm-commits]

dim added a comment.

In http://reviews.llvm.org/D15996#325896, @Meinersbur wrote:

> Is it undefined behaviour if it never executes?


At least for how the code is emitted, it is; e.g. everything after the first nullptr dereference was optimized away in the old code, defeating the purpose of the whole exercise.

On the other hand, the link failures I originally got were because Valgrind.cpp was not linked into the main clang executable, but apparently the only thing requiring functions from this file is this ForcePassLinking part!  I looked through the whole llvm+clang source tree, and only bugpoint.cpp calls `RunningOnValgrind()`.

So maybe at some point we may be able to ditch this header altogether? :-)  I would be more inclined to do find a way to do that...

> IMHO the complete function already relies on assumptions made on how intelligent today's compilers work as the initial comment states, so even whether any of the functions is linked in is undefined.

> 

> I have another suggestion how to to the same thing in a more conformant way:

> 

>   (ForcePassLinging*)()[] = { &llvm::createAAEvalPass, &llvm::createAggressiveDCEPass, ... }

>   auto ForceRegionPassLinking = &llvm::Function::Create

>    

> 

> Because the global variables are not static the compiler has to assume that these might be used somewhere else. LTO might remove it but that would be okay because it still has to execute the pass registration since the object file in question is linked-in.

> 

> Will still try with Polly on Windows


I'd be interested in the effects of simply removing the inclusion of this header in all files that currently use it, on Windows.  In combination with LTO, obviously.


http://reviews.llvm.org/D15996