[llvm-dev] assumptions about assume, was: RE: Early CSE clobbering llvm.assume
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 16 16:07:52 PDT 2016
----- 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
> Here’s a relatively simple question that should not start a runaway
> thread (!?)
> Is “assume” something the user supplies information with, like
> Or is “assume” something the compiler inserts as a result of
> 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.
> --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.
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev