[llvm-dev] Early CSE clobbering llvm.assume

[Davide Italiano via llvm-dev]

Sorry for resurrecting a 4 months old thread, but the issue I was
debugging today reminded me of its existence (and we hit a maybe
related problem while compiling lld with clang)
https://llvm.org/bugs/show_bug.cgi?id=30771#c1

On Tue, Jun 14, 2016 at 9:41 PM, Daniel Berlin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I suspect this thread has become deep enough that it is becoming somewhat
> unproductive and if we really want to carry it on, it may be more useful to
> do so at a social or something.
>
> I suspect this mainly because you can't tell who i'm quoting, and folks are
> replying to things other people have not quite said, due to the quoting :)
>
> There seem to be other confusions, such as use of common llvm terminology
> that is not always common in other parts of the world of compilers
> (unreachable, undef, etc).
>
> On Tue, Jun 14, 2016 at 7:04 PM, Lawrence, Peter <c_plawre at qca.qualcomm.com>
> wrote:
>>
>> Daniel,
>>
>>               This first part is to whoever you are quoting, I can’t tell
>> from the email,
>>
>>
>>
>> The more information made available to the optimizers the better the
>> optimizations,
>>
>> Asserts provide more information,
>>
>> You *should* expect better code with asserts enabled.
>>
>>
>>
>> And this is *not* a bad thing !!!
>>
>>
>>
>> And IMHO there is no winning argument that says we should not use this
>> information.
>>
>>
>>
>> In other words saying “asserts aren’t for optimization” isn’t a winning
>> argument,
>>
>> Its information and it isn’t useful to throw that information away.
>>
>> It’s not very far removed from saying “if, while, and for conditions”
>> aren’t for optimization.
>>
>>
>>
>>
>>
>>
>>
>> This second part is for your response,
>>
>>
>>
>> Hmmm, I don’t get how you go from “assert having a call to abort()” to a
>> bunch of talk
>>
>> About “branch around unreachable” ?  the condition isn’t unreachable, the
>> abort isn’t
>>
>> Unreachable, what’s unreachable ???
>>
>>
>>
>>
>>
>> --Peter.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: Daniel Berlin [mailto:dberlin at dberlin.org]
>> Sent: Tuesday, June 14, 2016 11:23 AM
>> To: Hal Finkel <hfinkel at anl.gov>
>> Cc: Lawrence, Peter <c_plawre at qca.qualcomm.com>; llvm-dev
>> <llvm-dev at lists.llvm.org>
>> Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume
>>
>>
>>
>>
>>
>> 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.
>>
>>
>>
>>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare