[PATCH] D128155: [GuardWidening] Use freeze to widen using possible poison value.

[Serguei Katkov via Phabricator via llvm-commits]

skatkov added a comment.

In D128155#3626453 <https://reviews.llvm.org/D128155#3626453>, @apilipenko wrote:

> Could you please give a brief outline of the approach?

Guard Widening uses two main ways to wide the current guard.
The second one is just combine conditions of two guards and apply it to the first one.
For this case we just use c1 & freeze(c2) in case we cannot prove that c2 is not a poison.
If we prove that c2 is not a poison the result is just c1& c2.

The first case is more complex.
First, it parses the conditions of first guard (guard to wide) and second one.
In case all conditions are and operation of "range checks" it will merge them.
Range check is a condition of the form base + offset unsigned less then length.
For each condition, case, offset and length can be different but offset must be an integer constant.
I try to reduce the number of freeze usages, so during the parsing we detect some facts.
While parsing the first guard we consider that all values do not require freeze due to if base or length were poison than
we had a UB(guard on poison value) in the original program so we do not care.
Parsing the second guard we conservatively suggest that freeze will be needed due to we will hoist the condition which potentially
may be a poison at the point of the first guard.
Also of we meet freeze instruction we go through it in parsing but consider that everything down require a freeze even if it comes from
the first guard (most probably it is a result of previous guard widening of the simple form).

Later optimization consider all Bi + OFFi < Li and split them into groups where Bi and Li are equal.
For each group it does the following:
if the size of the group is less then 3 then do not combine this group.
Otherwise if the OFFi from this group does not satisfy conditions required for this optimization Do not combine anything - just bailout.
Finally for this group combine all range checks and leave only B + OFFmin < L & B + OFFmax < L.
It is possible that both conditions comes from the second guard and will be hoisted so we need to freeze B and L.
However if B or L used in condition came from the first guard we can avoid freezing due to the same reason - we had UB in the original
program if B or L were poison.

After all groups are processed we combine all checks with arithmetic and operation but freeze those elements which require this.

I hope it helps.
the first guard


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

https://reviews.llvm.org/D128155