[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