[llvm-commits] [PATCH] Invariants (and Assume Aligned) - LLVM

[Hal Finkel]

----- Original Message -----
> From: "Nuno Lopes" <nunoplopes at sapo.pt>
> To: "Dan Gohman" <dan433584 at gmail.com>, reviews+D150+public+94bd4758cb777256 at llvm-reviews.chandlerc.com
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Thursday, December 6, 2012 4:57:02 PM
> Subject: Re: [llvm-commits] [PATCH] Invariants (and Assume Aligned) - LLVM
> 
> > This patch assumes that asserted conditions are globally true. This
> > significantly restricts their usefulness. Everything's easy if we
> > just
> > think about asserting properties for an entire function:
> >
> > void foo(void *p) {
> >  __builtin_assume(p is aligned or whatever);
> >  use(p);
> > }
> >
> > However, as soon as a function like this can get inlined into a
> > perfectly reasonable callsite like this:
> >
> >  if (p is aligned or whatever)
> >    foo(p);
> >  else
> >    do_something_slow(p);
> >
> > it doesn't work anymore, because it would apply to all uses of p in
> > the caller, including uses where p isn't aligned.
> >
> > It seems that the intuitive semantics would be that an assertion
> > should hold for all the uses dominated by an assertion statement.
> > Requiring dominator trees for anything that wants to use assertion
> > information would unfortunately keep it out of instcombine, where
> > it
> > would be very useful, so this is a significant problem. The
> > tentatively established way to solve this kind of problem is to
> > make
> > the assertion return a copy of the value it is asserting a
> > predicate
> > about. Something like this:
> >
> >  pp = __buiiltin_assume(p, p != 0);
> 
> That starts sounding like SSI's pi nodes:
> p = ...;
> if (...) {
>     pp = pi(p);
>     use (pp)
> }
> assume(pp != 0);

Yes, good point. We can think of these as like information-changing-phi nodes ;)

> 
> 
> Then assumptions can be global again, since copies of vars are
> created where
> necessary.
> 
> 
> > The other big topic to discuss in this patch is ephemeral values.
> > This
> > would be a significant landmark change.
> >
> > Ephemeral values add uses of values to the program which wouldn't
> > otherwise be there. This has its purpose of course, but also its
> > downsides, as it will interfere with use_empty() and hasOneUse()
> > optimizations (much of instcombine, etc.). It could easily be a
> > dickens for indvars and lsr, unless, again, it gets the right
> > special-case handling. It'll need special-casing in several
> > analyses
> > which walk def-use lists. The new EphemeralValues analysis pass
> > will
> > make the special-casing less painful, but it's still a value map
> > that
> > has to be passed around and kept current.
> 
> Yes, I'm also worried about the burden for each optimization.
> On the other hand, the code for invariants is single-path, so it's
> not that
> bad, since e.g. it won't confuse the single-BB-loop kind of
> optimizations.
> Some time ago we discussed the creation of a separate mini-language
> to
> specify invariants and other stuff that could be used in metadata. I
> think
> debug info was another potential client for this language. As well as
> assertions about buffer sizes. But it's a big project..
> 
> BTW, I think ephemeral calls should be limited to readnone
> (readonly?)
> functions. Stating assumptions and get side-effects at the same time
> doesn't
> really make sense. And assume() may or may not be deleted in between.

Agreed. We need something like IntrReadArgMem to make sure that the function, if it reads something, does not read any non-constant global state.

 -Hal

> 
> Nuno
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory