[PATCH] D20178: Fix PR26055 - LiveDebugValues is very slow

[Adrian Prantl via llvm-commits]

> On May 25, 2016, at 1:27 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> 
> Yeah, i honestly don't know.
> It's a need way to avoid constructing a real hash, my next question would be "is it actually demonstrably slower to compute a hash for real"?
> 
> Also, since the stuff is constant anyway, can't you just compute it at init time anyway?
> It's not like you have to compute it repeatedly.

The hash is only used for comparison in operator< and operation== so we can sort VarLoc. My idea was that we will eventually add other kinds of locations that are all at max 64 bits long and that they would all alias with the 64-bit hash value in the union, so we don’t have to implement different comparison operators for each member of the union or waste extra space for the hash.
I think should at least add a
      static_assert((sizeof(Loc) == sizeof(uint64_t)), "hash does not cover all members of Loc”);
to ensure that this invariant holds.

-- adrian

> 
> 
> 
> On Wed, May 25, 2016 at 1:15 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> aprantl added inline comments.
> 
> ================
> Comment at: lib/CodeGen/LiveDebugValues.cpp:103
> @@ +102,3 @@
> +      } RegisterLoc;
> +      uint64_t Hash;
> +    } Loc;
> ----------------
> dberlin wrote:
> > Errr, do you really never use the hash and the registerloc at the same time?
> >
> The hash is meant to be a convenient alternative view of the the two uint32_t as a single uint64_t. Now that I think of it, I wonder whether that is guaranteed on all imaginable architectures.
> 
> 
> http://reviews.llvm.org/D20178 <http://reviews.llvm.org/D20178>
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160525/1e418b72/attachment.html>