[LLVMdev] RFC: Proposal for Poison Semantics

[Bruce Hoult]

I don't see how it changes the meaning of the program whether the compiler
notices that two variables will always be 10 and 9 and does a compile time
evaluation of 10 + 9 = 19, or generates an add instruction that turns out
to  calculate the same result at runtime?

If you outline a function as you suggest, and then as a result don't know
the return value, it just means you generate actual instructions to use
that result as the programmer directed, rather than compile time
propagating a constant 19 to whatever follows.

On Mon, Feb 2, 2015 at 10:06 AM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> > I don't know how things work at the moment, but it seems to me that you
> can
> > do lots of sensible things, and avoid lots of silly things, if you keep
> > track of four possible values for each bit:
> >
> > - undef (the default)
> > - poison
> > - known to be 0
> > - known to be 1
>
> I'm not clear what you mean by "known to be X", but assuming you mean
> "known" in the same sense of computeKnownBits, then I don't think such
> a distinction will lead to intuitive semantics.  If the semantics of a
> program depended on what the compiler can prove about the program,
> then the meaning of a program will change based on how smart the
> compiler is (i.e. does the /compiler/ know that `add i32 10, 9` is
> `i32 19`?).  As a concrete example, outlining a function to a separate
> module will no longer be a meaning preserving transform because then a
> bit could go from "known to be 0" to "nothing is known".
>
> Sorry for the tangent, in case you meant something completely
> different by "known". :)
>
> -- Sanjoy
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150202/fae940ba/attachment.html>