<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 2, 2013 at 10:31 AM,  <span dir="ltr"><<a href="mailto:dag@cray.com" target="_blank">dag@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">Nadav Rotem <<a href="mailto:nrotem@apple.com">nrotem@apple.com</a>> writes:<br>
<br>
><br>
>         For DIV/MOD you can blend the inputs BEFORE the operation. You<br>
>         can<br>
>         place ones or zeros depending on the operation.<br>
><br>
>     Quick follow-up on this. What about using "undef" as the input for<br>
>     false items:<br>
><br>
>     tv1 = select mask, v1, undef<br>
>     tv2 = select mask, v2, undef<br>
>     tv3 = div tv1, tv2<br>
>     v3 = select mask, tv3, undef<br>
><br>
>     I'm always confused about the semantics of undef. Is the above<br>
>     safe<br>
>     code? It would simplify things a bit not to have to track which<br>
>     input<br>
>     values are safe based on the context of an operation.<br></div></div></blockquote><div><br></div><div style>The selects with undef do indeed do what you intend here. They return vectors where the elements corresponding to true bits in the mask have defined values, and the other elements have undef values. Undef can indeed exist on a per-element basis, and LLVM is quite careful to implement this [0].</div>
<div style><br></div><div style>The real problem with this approach is that there's nothing guarding those undef elements from the div. If the undef elements happen to be 0, you'll divide by zero, which is undefined behavior. For a divide, it's either necessary to define the behavior of divide-by-zero (not what LLVM does today), or mask the divide itself.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
><br>
>     -David<br>
><br>
> This is not a correct use of undef. I think that<br>
> InstCombine/DagCombine will optimize tv1 into 'undef'.<br></div></div></blockquote><div><br></div><div style>It is not valid to optimize tv1 to undef here. tv3 is the problem.</div><div style><br></div><div style>
Dan</div><div style><br></div><div style>[0] undef can also exist on a per-bit basis: and(1, undef) is a value where the least significant bit is undef and the remaining bits are zero. Amusingly, undef can also exist on a non-bitwise basis: add(mul(urem(undef, 3), 17), 5) is a value which fluctuates among just the values 5, 22, and 39.</div>
<div style><br></div></div></div></div>