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

Richard Diamond via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 3 12:29:40 PST 2015


On Mon, Nov 2, 2015 at 9:16 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> I'm very unclear and why you think a generic black box intrinsic will have
> any different performance impact ;-)
>
>
> I'm also unclear on what the goal with this intrinsic is.
> I understand the symptoms you are trying to solve - what exactly is the
> disease.
>
> IE you say "
>
> I'd like to propose a new intrinsic for use in preventing optimizations
> from deleting IR due to constant propagation, dead code elimination, etc."
>
> But why are you trying to achieve this goal?
>

It's a cleaner design than current solutions (as far as I'm aware).


> Benchmarks that can be const prop'd/etc away are often meaningless.
>

A benchmark that's completely removed is even more meaningless, and the
developer may not even know it's happening. I'm not saying this intrinsic
will make all benchmarks meaningful (and I can't), I'm saying that it would
be useful in Rust in ensuring that tests/benches aren't invalidated simply
because a computation wasn't performed.

Past that, if you want to ensure a particular optimization does a
> particular thing on a benchmark, ISTM it would be better to generate the
> IR, run opt (or build your own pass-by-pass harness), and then run "the
> passes you want on it" instead of "trying to stop certain passes from doing
> things to it".
>

True, but why would you want to force that speed bump onto other
developers? I'd argue that's more hacky than the inline asm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/ce6d1a5c/attachment.html>


More information about the llvm-dev mailing list