Displaying 10 results from an estimated 10 matches for "foodtaster".
2011 Dec 06
2
[LLVMdev] The nsw story
...br i1 %t3, ...
>
> The extra branching is gone, yay. But now we've put an add nsw out there
> to be executed unconditionally. If we make the select an observation
> point, we'd have introduced undefined behavior on a path that didn't
> previously have it.
>
> A foodtaster instruction doesn't really solve this problem, because
> we'd have to put it between the add and the select, and it would be
> just as problematic.
>
> The current definition of nsw is an attempt to avoid arbitrary
> limitations and keep the system as flexible as possible.
&...
2011 Dec 06
0
[LLVMdev] The nsw story
...a 'check' to sanitize them.
>
> So, if a potentially poison value propagates down the def-use graph
> until it reaches a store/select/compare, that instruction must be
> preceded by a 'check' that will sanitize the value.
>
> (Or maybe we should call it the 'foodtaster' instruction, which protects
> the important instructions from poison...)
>
> Separating out the induce-undefined-behavior instruction means the
> existing semantics of store/select/compare are unaffected, the main
> consequences being that you can't move these guys past the...
2011 Dec 06
3
[LLVMdev] The nsw story
...ations would subsequently need a 'check' to sanitize them.
So, if a potentially poison value propagates down the def-use graph
until it reaches a store/select/compare, that instruction must be
preceded by a 'check' that will sanitize the value.
(Or maybe we should call it the 'foodtaster' instruction, which protects
the important instructions from poison...)
Separating out the induce-undefined-behavior instruction means the
existing semantics of store/select/compare are unaffected, the main
consequences being that you can't move these guys past the 'check'
that fee...
2011 Dec 06
2
[LLVMdev] The nsw story
...ake the select an observation
> point, we'd have introduced undefined behavior on a path that didn't
> previously have it.
Unless the undefined behavior only triggered if the select actually
produced a poisoned result. Then it should have the same behavior as
the branch, no?
> A foodtaster instruction doesn't really solve this problem, because
> we'd have to put it between the add and the select, and it would be
> just as problematic.
Or you put it immediately after the select.
> One could argue that aggressive speculation is a low-level optimization
> better su...
2011 Dec 06
0
[LLVMdev] The nsw story
...sent in IR. It isn't ammenable to CFG+SSA form.
>
> Runtime checking for undefined behavior would be implemented as
> overflow checks, etc. by the front end. I don't think it's related to
> unsafe speculation. In other words, I don't see the purpose of a
> "check/foodtaster" instruction.
The purpose of all of these discussions is to alleviate the
computational explosion of static analysis that Dan described in the
presence of nsw bits. The point is to reduce the search space for
static checking. If we don't care about that, then all of this
discussion is m...
2011 Dec 06
0
[LLVMdev] The nsw story
...; point, we'd have introduced undefined behavior on a path that didn't
> > previously have it.
>
> Unless the undefined behavior only triggered if the select actually
> produced a poisoned result. Then it should have the same behavior as
> the branch, no?
>
> > A foodtaster instruction doesn't really solve this problem, because
> > we'd have to put it between the add and the select, and it would be
> > just as problematic.
>
> Or you put it immediately after the select.
>
That was my thinking. The select is an observation point for its fi...
2011 Dec 07
2
[LLVMdev] The nsw story
...> point, we'd have introduced undefined behavior on a path that didn't
> > previously have it.
>
> Unless the undefined behavior only triggered if the select actually
> produced a poisoned result. Then it should have the same behavior as
> the branch, no?
> > A foodtaster instruction doesn't really solve this problem, because
> > we'd have to put it between the add and the select, and it would be
> > just as problematic.
>
> Or you put it immediately after the select.
>
> That was my thinking. The select is an observation point for...
2011 Dec 06
0
[LLVMdev] The nsw story
...9;t ammenable to CFG+SSA form.
>>
>> Runtime checking for undefined behavior would be implemented as
>> overflow checks, etc. by the front end. I don't think it's related to
>> unsafe speculation. In other words, I don't see the purpose of a
>> "check/foodtaster" instruction.
>
> The purpose of all of these discussions is to alleviate the
> computational explosion of static analysis that Dan described in the
> presence of nsw bits. The point is to reduce the search space for
> static checking. If we don't care about that, then al...
2011 Dec 05
0
[LLVMdev] The nsw story
On Dec 5, 2011, at 11:55 AM, Paul Robinson wrote:
>
> On Thu, Dec 1, 2011 at 9:37 AM, David A. Greene <greened at obbligato.org> wrote:
> Dan Gohman <gohman at apple.com> writes:
>
> > Prohibiting poison values from propogating through memory would mean
> > that the reg2mem pass would no longer be a semantics-preserving pass.
>
> Or it means you
2011 Dec 05
3
[LLVMdev] The nsw story
On Thu, Dec 1, 2011 at 9:37 AM, David A. Greene <greened at obbligato.org>wrote:
> Dan Gohman <gohman at apple.com> writes:
>
> > Prohibiting poison values from propogating through memory would mean
> > that the reg2mem pass would no longer be a semantics-preserving pass.
>
> Or it means you couldn't demote those values.
If reg2mem is constructing spill