[llvm-dev] Early CSE clobbering llvm.assume

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 14 11:22:46 PDT 2016

>> Sanjoy’s argument is faulty, if it were true we would also find our
>> handling of “assert” to be unacceptable
>> but this is not the case, no one is arguing that we need to re-design
>> “assert”
> Sure, but no one should make this argument anyway: assert is not for
> optimization. In fact, we don't really want it to be used for optimization,
> because if we do, then we might end up in a situation where the -DNDEBUG
> build generates worse code than the build with asserts enabled.


> Also, I'll note that the reason that assume is an intrinsic, instead of a
> branch around unreachable, is that we aggressively remove branches around
> unreachable as part of our canonicalization process. We do this in order to
> simplify code, and this is important in order to remove abstraction
> penalties. Note that unreachables are also generated from undefined
> behavior, and one of the ways we use undefined behavior is to assume it is
> unreachable, enabling us to eliminate what should be dead code. This is an
> important technique for limiting abstraction penalties from, for example,
> heavily templated C++ code.
> Thus, somewhat unfortunately, Sanjoy's argument is not faulty.
> Asserts occur much more often than assumes, it may or may not be sensible
> to handle them the same way.
> I would argue it is sensible, but it's also reasonable to argue it is not.
> We need to be careful what we mean by "in the same way".

Yes, i simply meant "extract information from the control flow structure
and comparisons they generate when they are enabled".

You are correct with all of your observations :)

> We can certainly improve the representations of assumes, perhaps as Danny
> has suggested by converting their control dependencies into extended SSA
> token vales, and better capture knowledge from conditional branches, but
> the tradeoffs here are not trivial.
100% agreed, this is something that requires some exploration and messing
around, and then a design document going through the tradeoffs of various
approaches with real data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160614/0d472154/attachment.html>

More information about the llvm-dev mailing list