<div dir="ltr"><div><div><div>Continuing going through the regression, another big source are loads, folded as (anyext/zext/sext/bitcast (load x)) -> (load any/zext/sext/from x)<br><br></div>Numerous patterns then try to match some ext or bitcast, end up finding a load and bail. This is really pervasive and would likely require its own solution. Any ideas how to proceed?<br><br></div>Thanks,<br><br></div>Amaury Séchet<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 27 août 2019 à 13:33, Amaury Séchet <<a href="mailto:deadalnix@gmail.com">deadalnix@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>That is a great first step. It makes things better indeed, but still causes a few regression when nodes processing happens in a different order.<br><br></div>Roman patches seems to be the way to go.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 27 août 2019 à 00:18, Craig Topper via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I pushed it to a later DAG combine in r369981. Let me know if you still have problems from it.<div><br clear="all"><div><div dir="ltr" class="gmail-m_-5313277219970004067gmail-m_-5659132055190048163gmail_signature">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 26, 2019 at 1:02 PM Sanjay Patel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">No objections from me to make it run later. I didn't see the potential conflicts when I added that code. Delayed combine, custom lowering, or DAGToDAGISel all seem like viable options to me.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 26, 2019 at 2:04 PM Roman Lebedev <<a href="mailto:lebedev.ri@gmail.com" target="_blank">lebedev.ri@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have previously posted these two patches:<br>
<br>
[X86][CodeGen][NFC] Delay `combineIncDecVector()` from DAGCombine to<br>
X86DAGToDAGISel<br>
<a href="https://reviews.llvm.org/D62327" rel="noreferrer" target="_blank">https://reviews.llvm.org/D62327</a><br>
<br>
[DAGCombine][X86][AArch64][AMDGPU][MIPS][PPC] (sub x, c) -> (add x,<br>
-c) vector edition.<br>
<a href="https://reviews.llvm.org/D62341" rel="noreferrer" target="_blank">https://reviews.llvm.org/D62341</a><br>
<br>
While they got stuck since i wasn't really interested in them<br>
(i'm mostly interested in scalars, not vectors...),<br>
i don't think there was any fatal roadblocks there,<br>
so i guess i should rebase them and see what's the status now.<br>
<br>
Roman.<br>
<br>
On Mon, Aug 26, 2019 at 8:56 PM Topper, Craig <<a href="mailto:craig.topper@intel.com" target="_blank">craig.topper@intel.com</a>> wrote:<br>
><br>
> I think DAGToDAG is too late because the build_vector has already been turned into a constant pool load by then so it’s a little difficult to get back. Maybe we can delay it to !DCI.isBeforeLegalizeOps()? That would at least let the first DAG combine and the post type legalization DAG combine see the add, 1.<br>
><br>
><br>
><br>
> +Sanjay as well<br>
><br>
><br>
><br>
> From: Amaury Séchet <<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>><br>
> Sent: Monday, August 26, 2019 10:48 AM<br>
> To: Topper, Craig <<a href="mailto:craig.topper@intel.com" target="_blank">craig.topper@intel.com</a>>; <a href="mailto:llvm-dev@redking.me.uk" target="_blank">llvm-dev@redking.me.uk</a>; <a href="mailto:efriedma@quicinc.com" target="_blank">efriedma@quicinc.com</a>; <a href="mailto:lebedev.ri@gmail.com" target="_blank">lebedev.ri@gmail.com</a>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> Subject: LLVM X86 backend combineIncDecVector's transform<br>
><br>
><br>
><br>
> Hi all,<br>
><br>
> As you knwo already, I'm trying to change DAGCombiner so that it process the nodes in topological order. Doing so is not difficult per se, but this creates various improvements and regression to the existing test suite. I'd like to work through as many of the regressions as possible ahead of time.<br>
><br>
> One source of such regressions is combineIncDecVector in the X86 backend. It changes (add X, 1) into (sub X, -1) in order to be able to use the pcmpeq instruction.<br>
><br>
> This is all well and good, but numerous paterns are matching an add rather than a sub, and in fact, DAGCombiner does the inverse transform by itself as it consider the add form to be canonical. An example of such pattern is the X86ISD::AVG node, but there are more.<br>
><br>
> It seems to me like this transformation is useful, but doesn't happen at the right place in the pipeline. Doing so later on, for instance at the DAG to DAG level would likely give DAGCombiner  more opportunities to do its job, and also ensure that all instances of the pattern are detected.<br>
><br>
> It would be great if someone familiar with the X86 backend could look into this.<br>
><br>
> Thanks in advance,<br>
><br>
> Amaury Séchet<br>
</blockquote></div>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>