[PATCH] D128877: [LoopCacheAnalysis] Fix a type mismatch bug in cost calculation

[Bjorn Pettersson via Phabricator via llvm-commits]

bjope added a comment.

Afaik getNoopOrAnyExtend() is defined as "If the type must be extended, it is extended with unspecified bits.". So you can't rely on it doing zero extend or sign extend. The extended bits are undefined.

That is probably OK in use-cases such as how getNoopOrAnyExtend is used in ScalarEvolutionExpander, when it is truncating the result from the add/mul expr that is using the extended size (i.e. the upper bits are of no interest anyway).
But I do not really see how the usage of getNoopOrAnyExtend() in LoopCacheAnalysis is safe in a similar manner. Those "undefined" bits seem to be significant both in the new Stride calculation in this patch, as well as in the already present code that for example is doing

  Stride = SE.getNoopOrAnyExtend(Stride, WiderType);
  TripCount = SE.getNoopOrAnyExtend(TripCount, WiderType);
  const SCEV *Numerator = SE.getMulExpr(Stride, TripCount);
  RefCost = SE.getUDivExpr(Numerator, CacheLineSize);

Or am I missing something?


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

https://reviews.llvm.org/D128877