[PATCH] Check for all known bits on ret in InstCombine

[Hal Finkel]

----- Original Message -----
> From: "Philip Reames" <listmail at philipreames.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvm-commits at cs.uiuc.edu, reviews+D4567+public+8b075aecf68909a0 at reviews.llvm.org, chandlerc at gmail.com
> Sent: Tuesday, July 22, 2014 1:24:59 PM
> Subject: Re: [PATCH] Check for all known bits on ret in InstCombine
> 
> 
> On 07/22/2014 10:25 AM, Hal Finkel wrote:
> >
> >> 2) When do we remove a llvm.assume? In your test case, you had an
> >> assume which (after the transform) retained a condition about an
> >> otherwise used value (%a). This seems like an obvious case to
> >> remove
> >> since we've gotten all the benefit we can from it. Are there other
> >> cases like this we should implement?
> > No, I disagree.
> This is exactly the discussion we need to be having then.  :)
> > We don't want to remove the invariants until after inlining is
> > complete. And for alignment guarantees, for example, we don't want
> > to remove them until after vectorization and unrolling. Currently,
> > they're removed on entry to CodeGen, and it is not clear to me
> > that we need or want to do anything else.
> I don't agree with this.  I see several cases where removing them
> early
> seems like a good idea.  Consider:
> - Once we recognize an assumption and canonicalize it as an
> attribute,
> we should immediately remove the assumption.  The assumption conveys
> no
> additional information and only limits optimization.  All of the
> semantic information is available in the attribute.  If your concern
> is
> that we loose this information on inlining, then maybe we need to
> address *that*.

Yes, this has always been the plan ;) -- assumptions should be turned into attributes when possible, and then upon inlining, they get turned back into assumptions.

> - Once the values which contribute to the assumption become otherwise
> dead, what does information about those values tell us? It seems like
> there's no profit to be had by keeping it.  (Thinking about it, my
> original question/proposal was wrong.  "%a" was a parameter.  There
> might be later uses of the value after inlining. For discussion,
> let's
> pretend "%a" had been the result of a pure function call or
> something.)

But the values need to come from somewhere. Maybe it was a load, but there could be value in keeping the assumption based on the loaded value after inlining too. I think that, until we have evidence otherwise, we'll eliminate only trivially true assumptions, trivially false/undefined ones (by turning them into unreachable), and keep everything else (where transforming it into a parameter/return attribute counts as keeping it).

Thanks again,
Hal

> 
> Philip
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory