[llvm-dev] [RFC] A new intrinsic, `llvm.blackbox`, to explicitly prevent constprop, die, etc optimizations

[Alex Elsayed via llvm-dev]

On Wed, 11 Nov 2015 11:13:43 -0800, Daniel Berlin via llvm-dev wrote:
<snip for gmane>
> Heck, i could even reason about inline asm if i wanted to ;-).
> 
> My point is that this call is super special compared to all other 
> calls,
> and literally everything in LLVM has to understand that.
> The liklihood of subtle bugs being introduced in functionality (IE
> analysis/etc doing the wrong thing because it is not special cased)
> seems super high to me.

I do agree this is a concern.
 
>> I don't know how you could practically deploy a super-duper LTO mode
>> that doesn't allow that as part of its model.
>>
>>
> Sure.
> 
> 
>> The following CFG simplification would be legal, as it also fits the
>> normal model of an external call:
>> if (cond) y =llvm.blackbox(x)
>> else y = llvm.blackbox(x)
>> -->
>> y = llvm.blackbox(x)
>>
>> I don't see how this is special. It just provides an overloaded
>> intrinsic whose definition we promise to never reason about. Other than
>> that it follows the same familiar rules that function calls do.
>>
>>
> You have now removed some conditional evaluation and  jumps.  those 
> would normally take benchmark time.
> Why is that okay?

Because the original post in terms of wanting to inhibit specific 
optimizations was a flawed way of describing the problem.

Reid's explanation of "an external function that LLVM is not allowed to 
reason about the body of" is a much better explanation, as a good 
benchmark will place llvm.blackbox() exactly where real code would call, 
say, getrandom() (on input) or printf() (on output).

However, as the function call overhead of said external function isn't 
part of the _developer's_ code, and not something they can make faster in 
case of slow results, it's not relevant to the benchmarks - thus, using 
an _actual_ external function is suboptimal, even leaving aside that with 
LTO and such, llvm may STILL infer things about such functions, obviating 
the benchark.

Perhaps the best explanation is that it's about *simulating the 
existence* of a "perfectly efficient" external world.