<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div apple-content-edited="true"><br>
</div>
<br><div><div>On Jun 28, 2013, at 10:32 AM, Eli Bendersky <<a href="mailto:eliben@google.com">eliben@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div 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;"><div dir="ltr">On Fri, Jun 28, 2013 at 9:47 AM, Quentin Colombet<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;">Hi Eli,<div><br></div><div>Just a thought, wouldn’t be better to add a hook in TargetSelectionDAGInfo for pow, just like memset and memmove?</div><div>Indeed, I guess that pow intrinsics may have special handling in some optimizations and I am afraid we lose those benefits with the proposed patch.</div><div><br></div><div>What do you think?</div></div></blockquote><div><br></div><div>Hi Quentin,</div><div><br></div><div>I suppose it can be useful, but IMHO it's an orthogonal issue to the Clang change. Some targets (like PNaCl, and possibly others that split the compilation to two distinct stages with bitcode in between) may decide that the hardcoded pow-->intrinsic translation Clang currently does is not necessarily desirable. The patch allows them to state so.</div></div></div></div></div></blockquote><div dir="auto">Make sense.</div><br><blockquote type="cite"><div 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;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>It could probably be generalized even more by providing targets with a stronger tool to state that they don't want intrinsics to be generated for known lib calls.</div></div></div></div></div></blockquote><div>That would be great and I guess it would be the next step.</div><div><br></div><div>I leave to the front-end specialist to comment on your patch :).</div><div><br></div><div>Thanks for your answer.</div><div><br></div><div>Cheers,</div><div><br></div><div>-Quentin </div><br><blockquote type="cite"><div 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;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>As for the SelDAG side, targets can probably already customize it by "legalizing" ISD::FPOW etc. in a special way? In any case, for split-compilation uses that's way too late :-)</div><div><br></div><div>Eli</div></div></div></div></div></blockquote></div><br></body></html>