<div class="gmail_quote">An attempt at clarification (I still am not going to pick a side here, I'm just interested in the results):</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Dec 12, 2011 at 3:47 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The feeling was that it regresses on useful functionality: a frontend may want "defined at zero semantics" and codegen should be able to legalize in a select if needed.</blockquote>
<div><br></div><div>I think Duncan agreed with this, but felt that codegen could match that pattern of code into the instruction where necessary. This seems plausible to me as it should merely be a comparison, the intrinsic, and a select. No CFG involved.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Having the undef bit also allows the optimizer to infer that the input can't be zero, allowing potentially cheaper instruction sequences to be synthesized by codegen etc.</blockquote>
</div><br><div>Also, I think Duncan is saying make the actual intrinsic spec that its result is undef for a zero input. Code which needs a defined result must use a comparison and a select to ignore the result of the intrinsic.</div>
<div><br></div><div>I think these are functionally equivalent. Let's call A the proposal I originally made (and which Duncan is arguing for), and B the current solution.</div><div><br></div><div>With A we have a simpler spec for the IR and for the ISD nodes in the codegen DAG. However, if a frontend wishes to provide a defined result for zero input, it must produce more complex IR, and if the backend wishes to produce efficient code for such constructs, it much use a more complex pattern.</div>
<div><br></div><div>With B we have a more complex spec for the IR, but it is now trivial for the frontend to select either behavior. The codegen DAG remains more complex in specification because we don't have the facilities in the codegen layer for manipulating immediates nearly as easily as we do in IR, and therefore we decompose the flag into two ISD nodes. I actually tried both implementations, and separate nodes was *significantly* simpler. Cases such as vector type legalization make it very useful to have the ISD nodes be unary. With B, the complexity in the backend is centered in the target-independent layer rather than in each target's patterns.</div>
<div><br></div><div><br></div><div>Anyways, I'm carrying on with implementing plan B as that was the favored one previously. If this discussion goes in a new direction, I'll happily convert everything to that new direction, be it plan A or plan C.</div>