[llvm-dev] InstSimplify and computeKnownBits
Craig Topper via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 17 13:29:15 PDT 2017
I wasn't trying to say anything about the number of constants with by
"less". Just about the effort we put in to try to make constants. For
example if you give instsimplify "add %x, 0" it will return %x and not do
anything with computing known bits and not create a constan. If you give
it "add %x, 1" and assuming we can't do some distributive simplication or
reassociation etc. it will fall back to computeKnownBits and might create a
On Mon, Apr 17, 2017 at 12:17 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> On Mon, Apr 17, 2017 at 10:22 AM, Craig Topper <craig.topper at gmail.com>
>> Today, InstSimplify calls computeKnownBits to try to fold to a constant
>> ONLY if it can't find any other simplifications for an instruction.
>> I think this means if we are able to find an earlier simplification we
>> are LESS aggressive about creating a constant because we won't even look at
>> known bits.
> Not necessarily.
> It may create more or less constants right now, not just strictly less.
> InstSimplify is not complete in it's transformations, so in some cases,
> the symbolic form is going to result in more simplified operations than the
> non-symbolic form.
> Now, how often does this happen?
> Again, hard to say. I would guess infrequently :)
> But it's definitely the case that because it is not complete, it is not a
> 100% improvement all the time to try to make as many constants as possible.
> If it *was* complete, there would be for sure.
> This seems surprising to me.
>> Should we be looking at known bits always, or should we remove this save
>> the compile time? How often does this allow us to simplify to a constant?
> It may be cheaper, compile time wise , to compute known bits non-lazily
> and look at it always than trying to use it always.
> As for how often it allows us to simplify to a constant, dunno, we should
> just track it.
> Add a statistic, see how it does :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev