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

[James Molloy via llvm-dev]

Hi,

I don't understand why in your benchmarks you're not just using an external
function, and then have an empty benchmark that just calls that external
function so you can know what overhead that adds. A bunch of benchmark
suites do this already, and chandler mentions it in the talk posted
earlier.

James
On Wed, 11 Nov 2015 at 21:02, Alex Elsayed via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151111/98bee232/attachment.html>