<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 2, 2015, at 2:19 PM, Owen Anderson <<a href="mailto:resistor@mac.com" class="">resistor@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 2, 2015, at 1:23 PM, Owen Anderson <<a href="mailto:resistor@mac.com" class="">resistor@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 2, 2015, at 1:08 PM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" class="">mehdi.amini@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I’m not sure backend specific transform can rely on the generic LLVM combiner not to canonicalize in a way that they “don’t like”. I think they have to handle the canonical form whatever it is.<span class="Apple-converted-space"> </span></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I suspect that many canonicalizations in general can go in the wrong direction in specific cases for specific targets.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">This is true, but it’s also worthwhile to consider ramifications for targets when choosing a canonical form. It’s generally not a good idea to pick a canonical representation that is the opposite of what every backend wants. In this case, it might not be every backend, but it does seem like there’s a class of processors for which this might not be desirable, and it’s worth considering that when choosing which form to consider canonical. I’m not interested in dictating the outcome of that consideration, but it’s still a consideration to be made.</div></div></div></blockquote><br class=""></div><div class="">Also, canonicalizing (fsub (fneg A), B) -> (fneg (fadd A, B)) is in conflict with existing canonical forms in SelectionDAG, which generally tries to move FNEG’s upwards in expression trees.</div></div></div></blockquote><div><br class=""></div></div>To be clear: i was not suggesting that one form was better than the other, my point was just that a particular backend cannot try to combine generic ISD node in a different way than the generic one.<div class="">And since you can have in general situation where there can be conflicting interest, a (especially out-of-tree) particular backend cannot expect that such canonicalization won’t be added.</div><div class="">Or, said differently, it is not because the generic SelectionDAG does not apply a canonicalization today that it might not chose one tomorrow. If you have an out-of-tree backend and you chose to canonicalize generic ISD instead of pushing upstream to have one form adopted, you can’t complain...<br class=""><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div></div></body></html>