[llvm-dev] Early CSE clobbering llvm.assume

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 14 20:42:09 PDT 2016


On Tue, Jun 14, 2016 at 7:04 PM, Lawrence, Peter via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> The more information made available to the optimizers the better the
> optimizations,
>
> Asserts provide more information,
>
> You *should* expect better code with asserts enabled.
>
> And this is *not* a bad thing !!!
>
> And IMHO there is no winning argument that says we should not use this
> information.
>
> In other words saying “asserts aren’t for optimization” isn’t a winning
> argument,
>
> Its information and it isn’t useful to throw that information away.

I think what you're missing (and something I've tried to highlight
above) is that control flow does not just add information, but it also
takes away information (so adding control flow is not an obvious net
win, and there is a trade-off).

E.g. the compiler can prove

%t0 = load i32, i32* %ptr0
%t1 = load i32, i32* %ptr1

is equivalent to

%t1 = load i32, i32* %ptr1
%t0 = load i32, i32* %ptr0

but it cannot prove

%t0 = load i32, i32* %ptr0
if (!PREDICATE(%t0)) { fail_assert("msg0"); unreachable; }
%t1 = load i32, i32* %ptr1
if (!PREDICATE(%t1)) { fail_assert("msg1"); unreachable; }

is the same as

%t1 = load i32, i32* %ptr1
if (!PREDICATE(%t1)) { fail_assert("msg1"); unreachable; }
%t0 = load i32, i32* %ptr0
if (!PREDICATE(%t0)) { fail_assert("msg0"); unreachable; }

because it isn't.

In particular, without the control flow it is trivial to show that
%ptr1 can be safely dereferenced at before the load from %ptr1, since
the program would have undefined behavior otherwise.  But with the
control flow you no longer know that, since the dereferenceability of
%t1 could be control dependent on PREDICATE(%t0) being true.

You could pattern match a specific call instruction "fail_assert" that
is known to be the "failing branch" of an assert; but that is not a
general solution, since code sinking will break that.

You also have compile time implications of having more basic blocks,
but that's secondary.

-- Sanjoy


More information about the llvm-dev mailing list