<div dir="ltr"><div><div><div><div><div><div><div>Resurrecting this thread.<br><br></div>After quite a lot of discussion with Matt on IRC, here are some conclusion and some experiment I came up with.<br></div><br> - getSetCCResultType use should probably limited to find the setcc result type based on setcc argument type. Using it to find out the expect type of a select's predicate based on the selected value type is an incorrect use. The use case here is isolated enough so I'm not sure it really make sense is backend agnostic code.<br></div> - Removing the optimization altogether break a bunch of tests. Backends expect it to work.<br></div> - Not truncating or extending the SetCC value seems to work. select node with different type for predicate and value is already supported, and we take advantage of this. Note: this used to break some tests on x86, but it doesn't anymore, so I suppose x86 target is now capable of handling this properly.<br></div> - I tried to Truncate if SetCC is larger than the selected values but keep different types if it is extended. This also seems to work properly.<br></div> - Using another type of extend (zero extend for instance) produce idiotic results.<br></div><div> - doing the sext or trunc after the select (sext_or_trunc (select, setcc, 0, -1)) work as well but will make x86 generate 64 bit select when 32 bits one would be sufficient. This either need to be handled in the target (but in this case, going for a more general solution is preferable IMO) so this seems to be the wrong balance.<br></div><div><div><br>Basically, the deeper question here is do we want to support predicate of different type that selected value. I think we want considering the various option explored here.<br><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-07-08 22:42 GMT-07:00 deadal nix <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The proposed patch would work for me. The combine make sense for me 100%
 of the time as my target can have different type for the setcc and the 
selected values. So if it is not in DAGCombiner, I'm going to end up 
doing it one way or another in the backend.</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-08 16:26 GMT-07:00 Matt Arsenault <span dir="ltr"><<a href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>></span>:<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div>
    <div>On 07/08/2014 03:20 PM, Matt Arsenault
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      Alternatively maybe this should only be done if the setcc type is
      the same as the sext result?<br>
    </blockquote></div>
    I think we should actually do this. If you need to convert the setcc
    result after, you aren't really gaining anything by doing this
    transformation<br>
  </div>

</blockquote></span></div><br></div>
</blockquote></div><br></div>