[PATCH] D64111: Add getMostFrequentByte and use for isBytewiseValue implementation

Vitaly Buka via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 12 15:22:07 PDT 2019


vitalybuka marked an inline comment as done.
vitalybuka added inline comments.


================
Comment at: llvm/lib/Analysis/ValueTracking.cpp:3182
   if (isa<UndefValue>(V))
-    return UndefInt8;
+    return;
 
----------------
jfb wrote:
> eugenis wrote:
> > vitalybuka wrote:
> > > jfb wrote:
> > > > Should `Undef` count as `Other`? Or have its own count?
> > > Undef means we don't care what it's there, so we can fill we any pattern.
> > > Other counts bytes which are different from most frequent value and will have to be fixed, e.g. after memset
> > Should we count undefs separately in the histogram? It seems like it would not add any complexity or runtime cost, and the caller can just add the two number if that's what they need.
> Right, it seems like we might want the following information:
> 
> * Value is one of 256 bytes were tracking.
> * Value wasn't something we looked into, for X bytes.
> * Value was `undef`.
> * Value was padding (same as `undef`).
> 
> We can figure out some of this, but not all, from the current patch. Is it useful to know the rest? I'm not sure! I haven't inspected all uses to be able to convince myself.
Right now I only use "count" and "other". Future users can easily count and return undefs and update interface if needed. But I would prefer to do so when needed. Also maybe at some point it would be useful to return entire histogram.

But I am OK to include undef if you believe it could be used soon.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64111/new/

https://reviews.llvm.org/D64111





More information about the llvm-commits mailing list