[llvm-dev] Early CSE clobbering llvm.assume

[Daniel Berlin via llvm-dev]

>
>
>> 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>