[llvm-dev] killing undef and spreading poison

[Daniel Berlin via llvm-dev]

On Thu, Jun 15, 2017 at 6:32 AM, Peter Lawrence <peterl95124 at sbcglobal.net>
wrote:

> Daniel,
>            Thanks for taking the time to respond.
>
> This is going to be my last response.


> Regarding GVN and newGVN, I recently finished a search through the
> llvm-dev archives for “nsw” in the subject line, and GVN was discussed in
> some of those threads [1].
>
> In particular it was claimed that there was a right choice for GVN to make
> given
> two ADD instructions, one with the “nsw” attribute and one without, the one
> without ‘nsw’ must be the representative.
>

GVN does not choose representatives based on the kind of attributes you
refer to because they are not properties of the value for the purposes of
representation, nor do i see how it would ever make sense to do so.
GVN can always patch the instructions after the fact to make sure the set
of attributes of the *operations* where the instructions occur is correct
for where they came from.



> This was described as a correctness issue, not an optimality issue. IE if
> you
> are going to CSE those two ADDs, it is safe to loose information (drop the
> ‘nsw’)
> but it is unsafe to put ‘nsw’ on to an operation that didn’t already have
> it
> because that is like inserting an “llvm.assume" where there was none.
>

This is unrelated to the choice of representative, and related to ensuring
that operations are modified for the properties of the representative
chosen.
Anything else would avoid value numbering

"add a, b" and "add nsw a, b"

to the same thing, when at worst, i just may have to drop the NSW if i
replace the second with the first
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170616/41cc7f2f/attachment.html>