[llvm-dev] ScalarEvolution "add nsw" question

Johannes Doerfert via llvm-dev llvm-dev at lists.llvm.org
Sun Apr 10 10:55:38 PDT 2016


Hello,

I was wondering under which circumstances ScalarEvolution will propagate
the no wrap flags from binary operators. In particular I looked at
non-loop carried code, e.g., as in the following function:

  int add(int x, int y) { return x + y; }

for which clang uses an "add nsw" instruction but ScalarEvolution does
not propagate this information. The -analyze output looks like this:

  Classifying expressions for: @add
    %add = add nsw i32 %x, %y
    -->  (%x + %y) U: full-set S: full-set

The piece of code that causes this (for me) unexpected result is located
in the ScalarEvolution::getNoWrapFlagsFromUB(...) function and looks
like this:

  if (InnermostContainingLoop == nullptr ||
      InnermostContainingLoop->getHeader() != BinOp->getParent())
    return SCEV::FlagAnyWrap;

If the "InnermostContainingLoop" is a nullptr, thus if the binary
operator is not contained in a loop, all overflow annotations are simply
discarded.

I do not know if I am missing something or if simply nobody cared so
far. In any case, I would appreciate any documentation on the current
implementation as well as pointer to were it could be improved.

Cheers,
  Johannes


P.S.
  I have another problem with the way we currently discard the "nsw"
  information for accesses ("gep inbounds" apparently only implies nuw).
  I will probably start another thread for that one [after I read the
  GEP handling in more detail].

-- 

Johannes Doerfert
Researcher / PhD Student

Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.31

Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160410/8ad3fb1f/attachment.sig>


More information about the llvm-dev mailing list