<div dir="ltr"><div>First, let's agree on terminology:</div><div>1. We're in LLVM. Clang has little or nothing to do with these questions from the perspective of LLVM developers.</div><div>2. The IR optimizer (also known as the middle-end and invoked via 'opt') is what takes LLVM IR from a front-end (clang is just 1 example) and transforms it to different LLVM IR for easier target-specific optimization.</div><div>3. The back-end (invoked using 'llc') is what takes LLVM IR and turns it into assembly for your target. Codegen is 1 part of the backend.<br></div><div><br></div><div>So yes, the IR optimizer (instcombine is the specific pass) sometimes turns icmp (and select) sequences into ALU ops. Instcombine is almost entirely *target-independent* and should remain that way. The (sometimes unfortunate) decision to create shifts were made based on popular targets of the time (PowerPC and/or x86), and other targets may have suffered because of that.<br></div><div><br></div><div>We've been trying to reverse those canonicalizations in IR over the past few years when the choice is clearly not always optimal, but it's not easy. To avoid perf regressions, you first have to make the backend/codegen aware of the alternate pattern that includes icmp/select and transform that to math/logic (translate instcombine code to DAGCombiner). Then, you have to remove the transform from instcombine and replace it with the reverse transform. This can uncover infinite loops and other problems within instcombine.</div><div><br></div><div>It's often not clear which form of IR will lead to better optimizations within the IR optimizer itself. We favor the shortest IR sequence in most cases. But if there's a tie, we have to make a judgement about what is easier to analyze/transform when viewed within a longer sequence of IR.<br></div><div><br></div><div>So to finally answer the question: If you can transform the shift into an alternate sequence with a "setcc" DAG node in your target's "ISelLowering" code, that's the easiest way forward. Otherwise, you have to weigh the impact of each target-independent transform on every target.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 30, 2019 at 5:31 PM Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@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"><div dir="ltr"><div>For the MSP430 example, I'm guess its InstCombiner::transformSExtICmp or InstCombiner::transformZExtICmp</div><br clear="all"><div><div dir="ltr">~Craig</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 30, 2019 at 2:21 PM Support IMAP <<a href="mailto:support@sweetwilliamsl.com" target="_blank">support@sweetwilliamsl.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"><div><div>Hi all,</div><div><br></div><div>Ok, I just found a much simpler example of the same issue.</div><div><br></div><div>Consider the following code</div><div><br></div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Monaco;background-color:rgb(255,255,255)"><span style="color:rgb(186,45,162)">int</span> cmpge32_0(<span style="color:rgb(186,45,162)">long</span> a) {</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Monaco;background-color:rgb(255,255,255)"> <span style="color:rgb(186,45,162)">return</span> a>=<span style="color:rgb(39,42,216)">0</span>;</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Monaco;background-color:rgb(255,255,255)">}</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Monaco;background-color:rgb(255,255,255)"><br></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Monaco;background-color:rgb(255,255,255)"><span style="font-family:Helvetica;font-size:12px">Compiled for the MSP430 with -O1 or -Os results in the following:</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Monaco;background-color:rgb(255,255,255)"><span style="font-family:Helvetica;font-size:12px"><br></span></div><div style="margin:0px;line-height:normal;background-color:rgb(255,255,255)"><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal">; Function Attrs: norecurse nounwind readnone</div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal">define dso_local i16 @cmpge32_0(i32 %a) local_unnamed_addr #0 {</div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal">entry:</div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal"> %a.lobit = lshr i32 %a, 31</div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal"> %0 = trunc i32 %a.lobit to i16</div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal"> %.not = xor i16 %0, 1</div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal"> ret i16 %.not</div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal">}</div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal"><span style="font-family:Helvetica;font-size:12px"><br></span></div><div style="margin:0px;line-height:normal"><font face="Monaco"><span style="font-size:11px">T</span></font><span style="font-family:Helvetica;font-size:12px">he backend then turns this into the following totally suboptimal code:</span></div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal"><span style="font-family:Helvetica;font-size:12px"><br></span></div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal"><div style="margin:0px;line-height:normal">cmpge32_<span style="color:rgb(39,42,216)">0</span>:</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>mov<span style="white-space:pre-wrap"> </span>r13, r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>inv<span style="white-space:pre-wrap"> </span>r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>swpb<span style="white-space:pre-wrap"> </span>r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>mov.b<span style="white-space:pre-wrap"> </span>r12, r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>clrc</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>rrc<span style="white-space:pre-wrap"> </span>r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>rra<span style="white-space:pre-wrap"> </span>r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>rra<span style="white-space:pre-wrap"> </span>r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>rra<span style="white-space:pre-wrap"> </span>r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>rra<span style="white-space:pre-wrap"> </span>r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>rra<span style="white-space:pre-wrap"> </span>r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>rra<span style="white-space:pre-wrap"> </span>r12</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>ret</div><div style="margin:0px;line-height:normal">.Lfunc_end0:</div><div style="margin:0px;line-height:normal"><span style="white-space:pre-wrap"> </span>.size<span style="white-space:pre-wrap"> </span>cmpge32_<span style="color:rgb(39,42,216)">0</span>, .Lfunc_end0-cmpge32_<span style="color:rgb(39,42,216)">0</span></div></div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal"><br></div><div style="font-family:Monaco;font-size:11px;margin:0px;line-height:normal"><span style="font-family:Helvetica;font-size:12px"><br></span></div><div style="margin:0px;line-height:normal">The cause of this anomaly is again the presence of the Shift instruction (<span style="font-family:Monaco;font-size:11px">%a.lobit = lshr i32 %a, 31) </span>at the IR level, which is hard to handle by the backend.</div><div style="margin:0px;line-height:normal"><br></div><div style="margin:0px;line-height:normal">The same C code compiled with -O0 creates the following IR code excerpt instead of the lshr-trunc code sequence</div><div style="margin:0px;line-height:normal"><br></div><div style="margin:0px;line-height:normal"><div style="margin:0px;font-size:11px;line-height:normal;font-family:Monaco"> %cmp = icmp sge i32 %0, 0</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Monaco"> %conv = zext i1 %cmp to i16</div></div><div style="margin:0px;line-height:normal"><br></div><div style="margin:0px;line-height:normal">This compiles into MUCH better code for the MSP430 architecture (and virtually any 16 bit architecture not supporting multiple shifts). </div><div style="margin:0px;line-height:normal">It would be desirable that LLVM would just leave the comparison as is, also for -O1 and above. </div><div style="margin:0px;line-height:normal"><br></div><div style="margin:0px;line-height:normal"><br></div><div style="margin:0px;line-height:normal">So Please, can somebody point me to the LLVM class or function that performs the transformation of the comparison above into the undesired shift, so I can investigate what’s going on, or whether there’s something I can do?</div><div style="margin:0px;line-height:normal"><br></div><div style="margin:0px;line-height:normal">That would be really appreciated.</div><div style="margin:0px;line-height:normal"><br></div><div style="margin:0px;line-height:normal">John</div></div></div><div><br></div><div><br>Hi Roman<br><br><blockquote type="cite">Not exactly, this is IR after optimizations, this is not what clang produces.<br>To see what clang produces you want to pass -O0.<br>All optimizations beyond that are done by LLVM.<br></blockquote><br><br>Ok, I understand such naming convention, but it is still something that happens at the IR code generation steps, and therefore the backend has little to do about. <br><br>So, what are actually the hooks that I can implement or investigate to modify the undesired behaviour?<br><br>John<br><br><br><blockquote type="cite">On 30 Sep 2019, at 13:35, Roman Lebedev <<a href="mailto:lebedev.ri@gmail.com" target="_blank">lebedev.ri@gmail.com</a>> wrote:<br><br>On Mon, Sep 30, 2019 at 11:52 AM Joan Lluch <<a href="mailto:joan.lluch@icloud.com" target="_blank">joan.lluch@icloud.com</a>> wrote:<br><blockquote type="cite"><br>Hi Roman,<br><br>Is "test" actually an implementation of a 64-bit-wide multiplication<br>compiler-rt builtin?<br>Then i'd think the main problem is that it is being optimized in the<br>first place, you could end up with endless recursion…<br><br><br>No, this is not a compiler-rt builtin. My example is of course incidentally taken from the implementation of a signed multiply, but as said, it has nothing to do with rt-builtins, I'm just using that code to show the issue. This function can’t create a recursion because it’s named ’test’, unlike any rt-buitin. You can replace the multiply in the source code by an addition, if you want to avoid calling rt-functions, but this does not change what I attempt to show. Also It’s not meant to be 64 bit wide, but 32 bit wide, because the targets I’m testing are 16 bit, so ints are 16 bit and longs are 32 bit. This is again the function I am testing:<br><br><br>long test (long a, long b)<br>{<br> int neg = 0;<br> long res;<br><br> if (a < 0)<br> {<br> a = -a;<br> neg = 1;<br> }<br><br> if (b < 0)<br> {<br> b = -b;<br> neg = !neg;<br> }<br><br> res = a*b;<br><br> if (neg)<br> res = -res;<br><br> return res;<br>}<br><br><br><br>LLVM, not clang.<br><br><br>I’m not sure about what you mean by that. The shown LLVM IR code is created by executing "clang” command line, so that’s what I attempt to show.<br></blockquote>Not exactly, this is IR after optimizations, this is not what clang produces.<br>To see what clang produces you want to pass -O0.<br>All optimizations beyond that are done by LLVM.<br><br><blockquote type="cite">So it’s actually the front-end that does such undesired optimisations sometimes, not only the LLVM back-end. This is in part why I am saying this is not right. See copied again the IR code that gets generated for the C code that I posted before. This IR code, including the presence of expensive shifts ( %a.lobit = lshr i32 %a, 31) is generated when -mllvm -phi-node-folding-threshold=1 is specified in the command line, or when the Target implements getOperationCost(unsigned Opcode, Type *Ty, Type *OpTy) to return TCC_Expensive for operator types that are bigger than the default target register size.<br><br><br><br>; ModuleID = 'main.c'<br>source_filename = "main.c"<br>target datalayout = "e-m:e-p:16:16-i32:16-i64:16-f32:16-f64:16-a:8-n8:16-S16"<br>target triple = "msp430"<br><br>; Function Attrs: norecurse nounwind optsize readnone<br>define dso_local i32 @test(i32 %a, i32 %b) local_unnamed_addr #0 {<br>entry:<br> %cmp = icmp slt i32 %a, 0<br> %sub = sub nsw i32 0, %a<br> %spec.select = select i1 %cmp, i32 %sub, i32 %a<br> %a.lobit = lshr i32 %a, 31<br> %0 = trunc i32 %a.lobit to i16<br> %cmp1 = icmp slt i32 %b, 0<br> br i1 %cmp1, label %if.then2, label %if.end4<br><br>if.then2: ; preds = %entry<br> %sub3 = sub nsw i32 0, %b<br> %1 = xor i16 %0, 1<br> br label %if.end4<br><br>if.end4: ; preds = %if.then2, %entry<br> %b.addr.0 = phi i32 [ %sub3, %if.then2 ], [ %b, %entry ]<br> %neg.1 = phi i16 [ %1, %if.then2 ], [ %0, %entry ]<br> %mul = mul nsw i32 %b.addr.0, %spec.select<br> %tobool5 = icmp eq i16 %neg.1, 0<br> %sub7 = sub nsw i32 0, %mul<br> %spec.select18 = select i1 %tobool5, i32 %mul, i32 %sub7<br> ret i32 %spec.select18<br>}<br><br>attributes #0 = { norecurse nounwind optsize readnone "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "min-legal-vector-width"="0" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }<br><br>!llvm.module.flags = !{!0}<br>!llvm.ident = !{!1}<br><br>!0 = !{i32 1, !"wchar_size", i32 2}<br>!1 = !{!"clang version 9.0.0 (<a href="https://github.com/llvm/llvm-project.git" target="_blank">https://github.com/llvm/llvm-project.git</a> 6f7deba43dd25fb7b3eca70f9c388ec9174f455a)"}<br><br><br><br>As you can see, Clang produces a 31 bit wide shift right ( %a.lobit = lshr i32 %a, 31) That’s the fourth instruction on the IR code above. So a shift is produced instead of creating a jump to a new block, as it should be the case as per the C source code.<br><br>Just as a matter of information. This is the implementation of the getOperationCost function that causes ‘clang’ to correctly replace selects by branches (desirable), but to generate shifts to fold expensive selects (undesirable)<br><br><br>unsigned CPU74TTIImpl::getOperationCost(unsigned Opcode, Type *Ty, Type *OpTy)<br>{<br> // Big types are expensive<br> unsigned OpSize = Ty->getScalarSizeInBits();<br> if ( OpSize > 16 )<br> return TTI::TCC_Expensive;<br><br> return BaseT::getOperationCost(Opcode, Ty, OpTy);<br>}<br><br>If the getOperationCost above function was not implemented, then clang would generate the usual series of ‘selects’. But this is even worse because selects imply speculative execution of expensive instructions, or duplicate branching created by the backend, which can’t be easily avoided.<br><br>Ideally, the IR code above should just place an ‘if.then' block for the if (a < 0) statement in the C source code, instead of attempting to replace a select by a shift (!)<br><br>If you want to play with these two scenarios, (1) IR code generated with branches, and (2) IR code generated with selects. This can easily be reproduced for the MSP430 target by compiling with the following options<br>(1) -mllvm -phi-node-folding-threshold=1 -c -S -Os<br>(2) -mllvm -phi-node-folding-threshold=2 -c -S -Os<br><br>For 16 bit targets without selects, or expensive selects, the overall code is better with (1) because that prevents the creation of a different jump for every ‘select’ that (2) would cause. However, the presence of the ‘shift’ instruction for (1) spoils it all.<br><br>Again, ideally, the use of shifts as a replacement of selects should be avoided, and an “if.then" block should be used as per the original C code.<br><br>I hope this is clear now.<br><br>John.<br><br><br>On 29 Sep 2019, at 15:57, Roman Lebedev <<a href="mailto:lebedev.ri@gmail.com" target="_blank">lebedev.ri@gmail.com</a>> wrote:<br><br>On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev<br><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br><br><br>Hi Sanjay,<br><br>Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it could do in some circumstances: The case of “OptSize" for targets not supporting Select was already mentioned to be detrimental.<br><br>For targets that actually have selects, but branches are cheap and generally profitable, particularly for expensive operators, the optimizeSelectInst function does not do good either. The function tries to identify consecutive selects with the same condition in order to avoid duplicate branches, which is ok, but then this effort is discarded in isFormingBranchFromSelectProfitable because the identified condition is used more than once (on the said two consecutive selects, of course), which defeats the whole purpose of checking for them, resulting in poor codegen.<br><br>Yet another issue is that Clang attempts to replace ‘selects’ in the source code, by supposedly optimised code that is not ok for all targets. One example is this:<br><br>LLVM, not clang.<br><br>long test (long a, long b)<br>{<br>int neg = 0;<br>long res;<br><br>if (a < 0)<br>{<br> a = -a;<br> neg = 1;<br>}<br><br>if (b < 0)<br>{<br> b = -b;<br> neg = !neg;<br>}<br><br>res = a*b; //(unsigned long)a / (unsigned long)b; // will call __udivsi3<br><br>if (neg)<br> res = -res;<br><br>return res;<br>}<br><br><br>This gets compiled into<br><br>; Function Attrs: norecurse nounwind readnone<br>define dso_local i32 @test(i32 %a, i32 %b) local_unnamed_addr #0 {<br>entry:<br>%cmp = icmp slt i32 %a, 0<br>%sub = sub nsw i32 0, %a<br>%a.addr.0 = select i1 %cmp, i32 %sub, i32 %a<br>%a.lobit = lshr i32 %a, 31<br>%0 = trunc i32 %a.lobit to i16<br>%cmp1 = icmp slt i32 %b, 0<br>br i1 %cmp1, label %if.then2, label %if.end4<br><br>if.then2: ; preds = %entry<br>%sub3 = sub nsw i32 0, %b<br>%1 = xor i16 %0, 1<br>br label %if.end4<br><br>if.end4: ; preds = %if.then2, %entry<br>%b.addr.0 = phi i32 [ %sub3, %if.then2 ], [ %b, %entry ]<br>%neg.1 = phi i16 [ %1, %if.then2 ], [ %0, %entry ]<br>%mul = mul nsw i32 %b.addr.0, %a.addr.0<br>%tobool5 = icmp eq i16 %neg.1, 0<br>%sub7 = sub nsw i32 0, %mul<br>%res.0 = select i1 %tobool5, i32 %mul, i32 %sub7<br>ret i32 %res.0<br>}<br><br>The offending part here is this: %a.lobit = lshr i32 %a, 31 . Instead of just creating a “select” instruction, as the original code suggested with the if (a < 0) { neg = 1;} statements, the front-end produces a lshr which is very expensive for small architectures, and makes it very difficult for the backend to fold it again into an actual select (or branch). In my opinion, the original C code should have produced a “select” and give the backend the opportunity to optimise it if required. I think that the frontend should perform only target independent optimisations.<br><br><br>You didn't specify how you compile that code.<br>We could also get: <a href="https://godbolt.org/z/B-5lj1" target="_blank">https://godbolt.org/z/B-5lj1</a><br>Which can actually be folded further to just<br>long test(long a, long b) {<br> return a * b;<br>}<br>Is "test" actually an implementation of a 64-bit-wide multiplication<br>compiler-rt builtin?<br>Then i'd think the main problem is that it is being optimized in the<br>first place, you could end up with endless recursion...<br><br>I posted before my view that LLVM is clearly designed to satisfy big boys such as the x86 and ARM targets. This means that, unfortunately, it makes too many general assumptions about what’s cheap, without providing enough hooks to cancel arbitrary optimisations. As I am implementing backends for 8 or 16 bit targets, I find myself doing a lot of work just to reverse optimisations that should have not been applied in the first place. My example above is an instance of a code mutation performed by the frontend that is not desirable. Existing 8 and 16 bit trunk targets (particularly the MSP430 and the AVR) are also negatively affected by the excessively liberal use of shifts by LLVM.<br><br>The CodeGenPrepare::optimizeSelectInst function needs some changes to respect targets with no selects, and targets that may want to avoid expensive speculative executions.<br><br>John<br><br>Roman<br><br>On 25 Sep 2019, at 16:00, Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>> wrote:<br><br>Changing the order of the checks in CodeGenPrepare::optimizeSelectInst() sounds good to me.<br><br>But you may need to go further for optimum performance. For example, we may be canonicalizing math/logic IR patterns into 'select' such as in the recent:<br><a href="https://reviews.llvm.org/D67799" target="_blank">https://reviews.llvm.org/D67799</a><br><br>So if you want those to become ALU ops again rather than branches, then you need to do the transform later in the backend. That is, you want to let DAGCombiner run its set of transforms on 'select' nodes.<br><br>On Wed, Sep 25, 2019 at 4:03 AM Joan Lluch via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br><br><br>Hi Craig,<br><br>Thank you for your reply. I have started looking at “CodeGenPrepare” and I assume you reffer to CodeGenPrepare::optimizeSelectInst. I will try to play a bit with that possibly later today. At first glance, it looks to me that for targets that do not support ’select’ at all, the fact that the function exits early for ‘OptSize’ can be detrimental, because this will just leave ALL existing selects in the code anyway. As said, I will try to play with that later, but right now it looks to me that maybe we should check for TLI->isSelectSupported earlier in the function, to get some more opportunities to such targets without explicit ’select’ support?<br><br>Thanks<br><br>John<br><br><br>On 25 Sep 2019, at 08:59, Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>> wrote:<br><br>There is code in CodeGenPrepare.cpp that can turn selects into branches that tries to account for multiple selects sharing the same condition. It doesn't look like either AVR or MSP430 enable that code though.<br><br>~Craig<br><br><br>On Tue, Sep 24, 2019 at 11:27 PM Joan Lluch via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br><br><br>Hi Roman,<br><br>Thank you for your reply. I understand your point. I just want to add something to clarify my original post in relation to your reply.<br><br>There are already implemented 8-bit and 16-bit backends, namely the AVR and the MSP430, which already "aggressively convert selects into branches”, which already benefit (as they are) from setting "phi-node-folding-threshold’ to 1 or zero. This is because otherwise Clang will generate several selects depending on the same “icmp”. These backends are unable to optimise that, and they just create a comparison and a conditional branch for every “select” in the IR code, in spite that the original C code was already written in a much better way. So the resulting effect is the presence of redundant comparisons and branches in the final code, with a detrimental of generated code quality.<br><br>The above gets improved by setting "phi-node-folding-threshold’ to 1 because some of these extra ‘selects' are no longer there so the backend stops generating redundant code.<br><br>John.<br><br><br><br><br>On 21 Sep 2019, at 14:48, Roman Lebedev <<a href="mailto:lebedev.ri@gmail.com" target="_blank">lebedev.ri@gmail.com</a>> wrote:<br><br>On Sat, Sep 21, 2019 at 3:18 PM Joan Lluch via cfe-dev<br><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br><br><br>Hi all,<br><br>For my custom architecture, I want to relax the CFG simplification pass, and any other passes replacing conditional branches.<br><br>I found that the replacement of conditional branches by “select" and other instructions is often too aggressive, and this causes inefficient code for my target as in most cases branches would be cheaper.<br><br>For example, considering the following c code:<br><br>long test (long a, long b)<br>{<br>int neg = 0;<br>long res;<br><br>if (a < 0)<br>{<br> a = -a;<br> neg = 1;<br>}<br><br>res = a*b;<br><br>if (neg)<br> res = -res;<br><br>return res;<br>}<br><br><br>This code can be simplified in c, but it’s just an example to show the point.<br><br>The code above gets compiled like this (-Oz flag):<br><br>; Function Attrs: minsize norecurse nounwind optsize readnone<br>define dso_local i32 @test(i32 %a, i32 %b) local_unnamed_addr #0 {<br>entry:<br>%cmp = icmp slt i32 %a, 0<br>%sub = sub nsw i32 0, %a<br>%a.addr.0 = select i1 %cmp, i32 %sub, i32 %a<br>%mul = mul nsw i32 %a.addr.0, %b<br>%sub2 = sub nsw i32 0, %mul<br>%res.0 = select i1 %cmp, i32 %sub2, i32 %mul<br>ret i32 %res.0<br>}<br><br><br>All branching was removed and replaced by ‘select’ instructions. For my architecture, it would be desirable to keep the original branches in most cases, because even simple 32 bit operations are too expensive to speculatively execute them, and branches are cheap.<br><br>Setting 'phi-node-folding-threshold’ to 1 or even 0 (instead of the default 2), definitely improves the situation in many cases, but Clang still creates many instances of ‘select’ instructions, which are detrimental to my target. I am unsure about where are they created, as I believe that the simplifycfg pass does not longer create them.<br><br>You definitively can't ban llvm passes/clang from creating select's.<br><br>So the question is: Are there any other hooks in clang, or custom code that I can implement, to relax the creation of ’select’ instructions and make it preserve branches in the original c code?<br><br>I think this is backwards.<br>Sure, you could maybe disable most of the folds that produce selects.<br>That may be good for final codegen, but will also affect other passes<br>since not everything deals with 2-node PHI as good as wit selects.<br><br>But, what happens if you still get the select-y IR?<br>Doesn't matter how, could be hand-written.<br><br>I think you might want to instead aggressively convert selects into<br>branches in backend.<br><br>Thanks,<br><br>John<br><br>Roman<br><br>_______________________________________________<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" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br><br><br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br><br><br><br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br><br><br><br>_______________________________________________<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" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br><br><br></blockquote></blockquote><br>_______________________________________________<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" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></div></blockquote></div>
</blockquote></div>