[llvm-dev] assumptions about assume, was: RE: Early CSE clobbering llvm.assume

[Hal Finkel via llvm-dev]

----- Original Message -----

> From: "Peter Lawrence" <c_plawre at qca.qualcomm.com>
> To: "Daniel Berlin" <dberlin at dberlin.org>
> Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev"
> <llvm-dev at lists.llvm.org>
> Sent: Thursday, June 16, 2016 6:02:22 PM
> Subject: assumptions about assume, was: RE: [llvm-dev] Early CSE
> clobbering llvm.assume

> Daniel,
> Here’s a relatively simple question that should not start a runaway
> thread (!?)

> Is “assume” something the user supplies information with, like
> “assert”,

> Or is “assume” something the compiler inserts as a result of
> analysis,

> I originally thought it was the former, but these various emails have
> convinced me
> That it is instead the later (except for the comment about
> “contracts”, which I hope
> We can leave out of the discussion for now).

It is generally the former, or it could be the frontend as a way to capture some aspect of the language semantics useful for optimization. Clang, for example, supports __builtin_assume (and __builtin_assume_aligned) which are implemented in terms of LLVM's assume facility. Some of the alignment-related attributes are also lowered this way. 

-Hal 

> --Peter Lawrence.

> (I also ask that no one replies to this thread saying that the user
> is not “supplying information”
> With assert, that is a separate thread !!!)

> From: Daniel Berlin [mailto:dberlin at dberlin.org]
> Sent: Tuesday, June 14, 2016 9:41 PM
> To: Lawrence, Peter <c_plawre at qca.qualcomm.com>
> Cc: Hal Finkel <hfinkel at anl.gov>; llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume

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

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160616/ee3a7648/attachment.html>