<div dir="ltr"><div>I agree. The comment about core code was just a generalization. It was just an alternative to a DAG solution for Vivek.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 5:04 PM, Jon Chesterfield <span dir="ltr"><<a href="mailto:jonathanchesterfield@gmail.com" target="_blank">jonathanchesterfield@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>That's interesting. What's the MI equivalent of the work list algorithm implemented by dag combine?</div><div dir="auto"><br></div><div dir="auto">In particular, I like that localised improvements to the dag are composed automatically and reasonably efficiently. I don't know how to achieve composition of back end passes beyond repeatedly applying the same sequence.</div><div dir="auto"><br></div><div dir="auto">Your comment about core code is lost on me though, extra isd nodes and the performDAGCombine hook have been sufficient so far.<br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 15 May 2017 21:36, "Ryan Taylor" <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>> wrote:<br type="attribution"><blockquote class="m_5915287180548360596quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Why not just create a backend pass to clean this up? Pattern shouldn't be too complicated to recognize in MI via use-def. Compartmentalized and you don't have to touch core code.</div><div class="m_5915287180548360596elided-text"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 4:29 PM, Jon Chesterfield via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi Vivek,<br><br></div><div class="gmail_extra">You could work around this by creating a custom ISD node, e.g. MyTargetISD::MyLSHR, with the same type as the general ISD::LSHR. This custom node will then be ignored by the generic DAGCombiner. Convert ISD::LSHR to MyTargetISD::MyLSHR in DAGCombine, optimise it as you see fit, convert it back or lower it directly.<br><br></div><div class="gmail_extra">I've done this for ISD::CONCAT_VECTORS to avoid an inconvenient conversion to ISD::BUILD_VECTOR. This looks a bit hacky though. I'll watch with interest for a more idiomatic solution.<br><br></div><div class="gmail_extra">Cheers<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
> On May 15, 2017, at 07:54, vivek pandya via llvm-dev <<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hello LLVM Developers,<br>
><br>
> I am working on an architecture which have one bit shift operation if<br>
> barrel shiftier hardware is not present in such cases some DAGCombine<br>
> optimizations reduces performance of certain benchmarks upto 5% for example<br>
> consider follwing optimization:<br>
> fold (select_cc seteq (and x, y), 0, 0, A) -> (and (shr (shl x)) A)<br>
> Here it introduce 2 shift operations and when barrel shiftier is not<br>
> present these shifts will be converted to loops thus making it worst. I am<br>
> sure there few architectures which have similar features. So how to disable<br>
> these kind of optimizations in DAGCombine particularly when I want build<br>
> and use LLVM for more than one target ?<br>
><br>
> Sincerely,<br>
> Vivek<br>
> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" rel="noreferrer">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
><br>
><br>
> Sounds to me like this combine is missing a TLI.isOperationLegal(ISD::LSHR<wbr>)<br>
> or similar check<br>
><br>
I think for me, problem will still be there because shift operation is<br>
legal on my target but it is able to shift only 1 bit at a time and that's<br>
why I need to convert to loop.<br>
-Vivek<br>
<br>
><br>
> -Matt<br>
><br></blockquote></div></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" rel="noreferrer">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>