[llvm] r233881 - Fix a bug indicated by -fsanitize=shift-exponent.

Sanjoy Das sanjoy at playingwithpointers.com
Sat Apr 11 17:21:23 PDT 2015


I redact my earlier statement about this not reproducing -- I can
easily reproduce this.  When I said this does not reproduce I was
stupidly looking at the C++ sieve benchmark, not the C one.

The problem is exactly what Alexey pointed out, earlier we were not
unrolling the inner loop in sieve while now we are:

    /* remove all multiples of prime: i */
    for (k=i+i; k <= 8192; k+=i) {
        flags[k] = 0;
    }

This is a regression because the runtime unrolling logic end up
emitting an expression to compute the trip count of the inner loop;
and this expression contains a `udiv`.

However, this is only half the story.  Before r229731 (that's when I
checked in the buggy left shift) there was no check on `Count`
(because it was not needed) so the unrolling should have been
happening before r229731 too.  The reason that did not happen was
because SCEV at r229731 was not smart enough to infer the trip count
of the inner loop.  After r231709 SCEV /can/ infer the trip count of
the inner loop and with Justin's change the inner loop now gets
unrolled.

-- Sanjoy

On Sun, Apr 5, 2015 at 10:27 PM, Justin Bogner <mail at justinbogner.com> wrote:
> Sanjoy Das <sanjoy at playingwithpointers.com> writes:
>> I'm having a hard time reproducing the regression locally. I
>> bootstrapped clang before and after r233881 with -flto and Release,
>> and both of them give me the same IR for the sieve benchmark (I'm on
>> Darwin and x86_64).  Is it possible to get some information out of the
>> buildbot that'll help in discovering what was actually run?
>
> I'll see if I can get anything from the bots or reproduce this
> tomorrow. If that doesn't pan out I'll try to find out if something
> environmental changed that could explain this.



More information about the llvm-commits mailing list