<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 12/07/2014 07:57 PM, Benjamin
      Poulain wrote:<br>
    </div>
    <blockquote cite="mid:548521B8.8080503@webkit.org" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      I looked into this today. <br>
      <br>
      Following your advice, I made something local to loop unrolling
      (patch attached). What this does is look if the previous block
      already checks for a trip count of zero.<br>
    </blockquote>
    Given the canonicalization introduced by loop rotation, this might
    be sufficient for many interesting cases.  You're basically taking
    advantage of the fact you know this is being inserted in a loop
    preheader.  <br>
    <blockquote cite="mid:548521B8.8080503@webkit.org" type="cite"> <br>
      This seems a bit hackish, it works for basic for() and while()
      loops. Is there an analysis pass I could use to track properties
      of values? I thought ScalarEvolution could help but it seems to
      only track that value inside the loop.<br>
    </blockquote>
    There is LazyValueInfo which is used by JumpThreading, but I suspect
    that's too expensive for this case.  There's also isKnownNonNull in
    ValueTracking, but that's not path sensitive.  (It doesn't hurt to
    leverage that anyway.)<br>
    <br>
    What you have seems like a reasonable starting point.  If you want
    to put it up on phabricator, I have a couple of small comments, but
    that's about it.  Opening a new thread is also a good way to get
    other eyes on the revised patch.  <br>
    <br>
    Structure wise, I think the following would be clearer for the
    actual test:<br>
    Value *LCmp = B.CreateIsNotNull(ModVal, "lcmp.mod");<br>
    Value *OverflowCheck = IsKnownNonZero(TripCount, PH) ?
    ConstantInt::getFalse(i1) : B.CreateIsNull(TripCount,
    "lcmp.overflow");<br>
    Value *BranchVal = B.CreateOr(OverflowCheck, LCmp, "lcmp.or");<br>
    <br>
    <br>
    <blockquote cite="mid:548521B8.8080503@webkit.org" type="cite"> <br>
      Benjamin<br>
      <br>
      <div class="moz-cite-prefix">On 12/2/14, 3:42 PM, Philip Reames
        wrote:<br>
      </div>
      <blockquote cite="mid:547E4E64.5080100@philipreames.com"
        type="cite">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
        Benjamin,<br>
        <br>
        This doesn't really feel like the right approach to the
        problem.  Adding another run of GVN after every unrolling
        opportunity is a fairly heavy weight hammer.  Have you looked to
        see if there's a simple change you could make to the unroller
        itself to handle this case?  I haven't looked at the code, but
        my suspicion is there would be.<br>
        <br>
        Philip<br>
        <br>
        <div class="moz-cite-prefix">On 11/29/2014 12:59 PM, Benjamin
          Poulain wrote:<br>
        </div>
        <blockquote cite="mid:547A33AB.1040105@webkit.org" type="cite">Hi,

          <br>
          <br>
          I noticed the optimized code generated for loops often include
          redundant checks that the size is not zero. <br>
          <br>
          For example, code like this: <br>
            unsigned total = 0; <br>
            for (unsigned i = 0; i < size; ++i) { ... <br>
          <br>
          when optimized, generate the following prologue: <br>
            entry: <br>
              %cmp4 = icmp eq i32 %size, 0 <br>
              br i1 %cmp4, label %for.end, label %for.body.lr.ph <br>
          <br>
            for.body.lr.ph:                                   ; preds =
          %entry <br>
             %0 = add i32 %size, -1 <br>
              %xtraiter = and i32 %size, 3 <br>
              %lcmp.mod = icmp ne i32 %xtraiter, 0 <br>
              %lcmp.overflow = icmp eq i32 %size, 0 <br>
              %lcmp.or = or i1 %lcmp.overflow, %lcmp.mod <br>
              br i1 %lcmp.or, label %for.body.prol, label
          %for.body.lr.ph.split <br>
          <br>
          Notice the redundant test for "icmp eq i32 %size, 0". When
          compiled to target, we have one redundant check per loop that
          can never be true. <br>
          <br>
          The extra check for size==0 comes from LoopUnroll. It is never
          optimized out because LoopUnrollPass is run after the passes
          that could eliminate redundant conditions. <br>
          <br>
          I have attached a patch that fixes the problem. For every pass
          of LoopUnroll, I added a GVN pass to remove every redundant
          conditions and branches. My patch is without test, I need
          guidance on how to properly test this. <br>
          <br>
          Benjamin <br>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
llvm-commits mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>