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

Alex Elsayed via llvm-dev llvm-dev at lists.llvm.org
Wed Nov 11 13:21:21 PST 2015


On Wed, 11 Nov 2015 13:15:45 -0800, Daniel Berlin via llvm-dev wrote:


>>
>>
>> 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,
> 
> 
> This isn't call overhead though.
> It's a conditional and two calls someone wrote in some benchmark code.
> That's not call overhead ;-)

I meant the prologue/epilogue of the external function, but James' 
response is relevant there.

> It's just that i've proven the condition has no side effects and doesn't
> matter, so i eliminated it.

Yes. That's perfectly fine. You could do the exact same thing with 
getrandom()'s result, or printf() calls.

That was my point.

> Thus, I'm trying to ask the question: "Will the use case really still be
> served if we let us eliminate these conditionals as useless, when the
> whole point is to let people test the overhead of things the compiler
> wanted to eliminate because it thinks they are useless"
> ;-)

And my answer was "Yes, emphatically so, as you're continually restating 
what I consider a deeply flawed summation of what it's trying to solve."

> the whole point is to let people test the overhead of things the
> compiler wanted to eliminate because it thinks they are useless"

This is _incorrect_.

The point is to _model the behavior of the benchmarked code AS IF the 
data goes to and comes from a place we know nothing about_.

These are fundamentally different things, which is why I keep restating 
it.



More information about the llvm-dev mailing list