This is an archive of the discontinued LLVM Phabricator instance.

[DemandedBits] Introduce a getMinimumBitWidth() member function
AbandonedPublic

Authored by jmolloy on Feb 15 2016, 5:42 AM.

Details

Reviewers
hfinkel
Summary

One of the major uses of DemandedBits is the loop vectorizer. It uses demandedbits to determine if an integer value can be losslessly truncated. This does not require the full power of demanded bits.

A non-demanded bit is a "don't care" bit - it can be changed to zero or one (or kept the same) without affecting the instruction's result. This is a powerful definition, but the loop vectorizer only needs a more limited form (which can be deduced in more situations) - "would removing this bit entirely affect the result?"

This can trigger in more situations because if we determine (via KnownBits) that a bit is part of a zero or sign extension, that bit can be happily removed (but not changed!)

This information is fairly trivial to track alongside AliveBits. We know track a set of "MustKeepBits" alongside AliveBits. MustKeepBits is a subset of the non-demanded bits (so MustKeepBits & AliveBits = 0). getDemandedBits(I) now changes from AliveBits[I] To AliveBits[I] | MustKeepBits[I].

This allows us to reenable tests that were removed following a revert due to PR26071.

I'm aware that the name "MustKeepBits" isn't perfect, and am open to bikeshedding.

Diff Detail

Repository
rL LLVM

Event Timeline

jmolloy updated this revision to Diff 47984.Feb 15 2016, 5:42 AM
jmolloy retitled this revision from to [DemandedBits] Introduce a getMinimumBitWidth() member function.
jmolloy updated this object.
jmolloy added a reviewer: hfinkel.
jmolloy set the repository for this revision to rL LLVM.
jmolloy added a subscriber: llvm-commits.

Ping! Hal, do you have comments on this?

hfinkel edited edge metadata.Feb 22 2016, 6:47 AM

I'll look at this in detail as soon as I can. In the mean time, a high-level question: Is this concept related to the "number of sign bits"? If so, should we have a call to ComputeNumSignBits (ValueTracking) somewhere?

Hi Hal,

Thanks for looking. You're right, that's something I'd missed. What I'm actually computing is the number of sign bits. I'm not sure about calling into ValueTracking though- I'll have a think about that.

James

jmolloy updated this revision to Diff 55200.Apr 27 2016, 6:04 AM
jmolloy edited edge metadata.

Hi Hal,

Sorry for the long trip time on this. This new patch has the same effect (in that it allows LoopVectorization to perform the same optimization), but is much cleaner and more well-defined.

Cheers,

James

hfinkel added inline comments.May 5 2016, 7:00 AM
include/llvm/Analysis/DemandedBits.h
72

It is not clear to me that we need a keep a bitset here. We could just keep an unsigned (a running count of the number of known sign bits).

lib/Analysis/DemandedBits.cpp
242

This logic seems non-obvious to me. Please add a comment. It looks like you're only keeping the sign bits that correspond to unset bits in the second xor operand. This is not the general case (xoring with -1 does not change the number of sign bits, for example).

277

I don't understand this logic at all. ICmp's return is the result of the comparison (i.e. an i1), and so the result is always trivial.

lib/Analysis/VectorUtils.cpp
370

Why do you use getLowBitsSet here and then use ~V1 below. Should we just get some number of set high bits?

jmolloy updated this revision to Diff 56564.May 9 2016, 6:13 AM
jmolloy abandoned this revision.May 9 2016, 7:38 AM
jmolloy marked an inline comment as done.

Abandoning this in favour of a much more simple solution in r268921.