<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 25, 2013 at 4:48 PM, Jim Grosbach <span dir="ltr"><<a href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>></span> wrote:<br>
<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"><br><div><div class="im">
<div>On Nov 22, 2013, at 7:26 PM, Sean Silva <<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Hi Jim,<br><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Fri, Nov 22, 2013 at 2:57 PM, Jim Grosbach <span dir="ltr"><<a href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>></span> wrote:<br>
<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">Author: grosbach<br>
Date: Fri Nov 22 13:57:47 2013<br>
New Revision: 195496<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=195496&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=195496&view=rev</a><br>
Log:<br>
X86: Perform integer comparisons at i32 or larger.<br>
<br>
Utilizing the 8 and 16 bit comparison instructions, even when an input can<br>
be folded into the comparison instruction itself, is typically not worth it.<br></blockquote><div><br></div><div>Could you cite experimental results backing this up? I have a hard time believing that this is true with such broad generality that the only reason to avoid following this advice is when optimizing for size.</div>
</div></div></div></blockquote><div><br></div></div><div>Agner and Intel’s own optimization guides agree that sub registers should be avoided.</div></div></div></blockquote><div><br></div><div>In the descriptions of the various AMD chips, Agner specifically says there is no issue of partial register stalls whatsoever. That's primarily why I am so skeptical.</div>
<div> </div><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"><div><div> They’re far more hardcore about it than I am in this patch, advocating avoiding them altogether. Testing for this patch backs up their assertions.</div>
<div><br></div><div>A few select examples I’m seeing are: 256.bzip2 improves by 7%. 401.bzip2 improves by 4.5%. 300.twolf improves by 3%. 186.crafty improves by 4%. The details vary, but this is true for both Ivy Bridge and Haswell in particular.</div>
<div><br></div><div>I have not been able to reproduce any regressions. If you have, I’d love to see the details so we can understand what’s happening and fix it.</div><div class="im"><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">
<div>I would expect conclusive benchmark results on a large corpus of code tested on a broad spectrum of microarchitectures from both Intel and AMD before making a change like this. Also, the code size impact needs to be quantified; having to break out to a whole new instruction for what would otherwise be an immediate has the potential for insane code-size increase (clang has something like 30,000 cmpb's and it seems like almost all of them have immediate memory operands). Also, not being able to fold a load into the comparison will likely increase register pressure.</div>
</div></div></div></blockquote><div><br></div></div><div>If you go back and look in the history of the changes to generate the partial register usage, as I did, you’ll find that code size was the motivation, not performance. This patch corrects a performance regression introduced by that change by using the min-size attribute (which post-dates the original patch). This is exactly the sort of thing that attribute is for.</div>
<div><br></div><div>This patch has indeed been tested with the llvm nightly test suite, including externals, and on other large codebases (Chandler can speak to those) across a large number of micro architectures from Intel and AMD. No regressions. Additionally, there was extensive investigation and conversation about the approach in person and in IRC.</div>
</div></div></blockquote><div><br></div><div>Apparently I missed those conversations. Oops!</div><div> </div><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"><div><div><br></div><div>That said, the bar you are setting here is absurdly high and impossible to meet pre-commit unless you want development to slow to an absolute crawl.</div></div></div>
</blockquote><div><br></div>This statement confuses me. Just above you said that "This patch has indeed been tested with the llvm nightly test suite, including externals, and on other large codebases (Chandler can speak to those) across a large number of micro architectures from Intel and AMD.", meaning that the bar I set was fulfilled in this case (also checking Chandler's email below reporting code size), so I'm not sure in what sense it is "absurdly high". Could you clarify what you mean here?</div>
<div class="gmail_quote"><br></div><div class="gmail_quote"><div>Also, the vast majority of changes don't affect bottom-line code generation/performance tweaks (almost all are either refactoring or working toward feature-completeness/compliance of some component) and wouldn't be affected by this kind of scrutiny anyway. Scanning my mailbox back in time, the most recent other case that I can seem to find was the recent SHLD/SHRD patch which also had been widely tested on many microarchitectures.</div>
<div><br></div><div>FWIW, I believe that this is is something that could be made a lot easier with better infrastructure in the future.</div><div> </div><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"><div><div>Short of major new features, this has never been required nor should it be required pre-commit. Again, if you have real example of regressions you believe are a direct result of this change, please raise them and we’ll have a look.</div>
<div><br></div><div>This patch is the right thing to do. The optimization guides agree and the empirical results back it up.</div></div></div></blockquote><div><br></div><div>In the future, please try to communicate something along the lines of this last sentence in your commit message, especially when there has been no mailing list discussion and there is no PR. When I read your commit message, it reads as a number of assertions about performance/experiments followed by a rdar link. My damn brain pattern-matched that to these salient properties:</div>
<div>1) The assertion as to the culprit being partial registers, which Agner specifically mentions aren't an issue for AMD, and</div><div>2) There's no mention of a public discussion, or PR, and the the only breadcrumbs about the thing it is apparently fixing leads to an internal bug tracker for a company that doesn't have any investment in AMD x86 chips. (although that sentiment instantly took a 180 upon hearing that there was public discussion and chandler took it for a spin etc.; I wish it had been communicated better to begin with)</div>
<div><br></div><div>Given that, I was naturally inclined to question how broadly this had been tested (in particular, whether AMD chips had been tested).</div><div><br></div><div>-- Sean Silva</div><div> </div><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"><div><div class="im"><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>At the very least I would expect a number of sample kernels showing definitive empirical performance improvements across a broad spectrum of micro architectures.</div></div></div></div></blockquote><blockquote type="cite">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><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">
There are too many partial register stalls as a result, leading to significant<br>
slowdowns. </blockquote><div><br></div><div>Most AMD architectures keep the whole register together internally, and so don't have partial register stalls (instead trading false dependencies). Does this change make sense on these uarches?</div>
</div></div></div></blockquote><div><br></div></div><div>Maybe? That’s a question better suited for someone more intimately familiar with those arches. I wouldn’t oppose making this Intel only if there’s good reason to do so.</div>
<div><div class="h5"><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div> </div><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">By always performing comparisons on at least 32-bit<br>
registers, performance of the calculation chain leading to the<br>
comparison improves. Continue to use the smaller comparisons when<br>
minimizing size, as that allows better folding of loads into the<br>
comparison instructions.<br>
<br>
<a>rdar://15386341</a><br>
<br>
Removed:<br>
llvm/trunk/test/CodeGen/X86/2007-10-17-IllegalAsm.ll<br></blockquote><div><br></div><div>What is the rationale for completely ripping out this testcase?</div><div> </div><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">
Modified:<br>
llvm/trunk/lib/Target/X86/X86ISelLowering.cpp<br>
llvm/trunk/test/CodeGen/X86/3addr-16bit.ll<br>
llvm/trunk/test/CodeGen/X86/codegen-prepare-extload.ll<br>
llvm/trunk/test/CodeGen/X86/ctpop-combine.ll<br>
llvm/trunk/test/CodeGen/X86/memcmp.ll<br>
llvm/trunk/test/CodeGen/X86/shrink-compare.ll<br>
<br>
Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=195496&r1=195495&r2=195496&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=195496&r1=195495&r2=195496&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original)<br>
+++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Fri Nov 22 13:57:47 2013<br>
@@ -3419,6 +3419,24 @@ bool X86::isCalleePop(CallingConv::ID Ca<br>
}<br>
}<br>
<br>
+/// \brief Return true if the condition is an unsigned comparison operation.<br>
+static bool isX86CCUnsigned(unsigned X86CC) {<br>
+ switch (X86CC) {<br>
+ default: llvm_unreachable("Invalid integer condition!");<br>
+ case X86::COND_E: return true;<br>
+ case X86::COND_G: return false;<br>
+ case X86::COND_GE: return false;<br>
+ case X86::COND_L: return false;<br>
+ case X86::COND_LE: return false;<br>
+ case X86::COND_NE: return true;<br>
+ case X86::COND_B: return true;<br>
+ case X86::COND_A: return true;<br>
+ case X86::COND_BE: return true;<br>
+ case X86::COND_AE: return true;<br>
+ }<br>
+ llvm_unreachable("covered switch fell through?!");<br>
+}<br>
+<br></blockquote><div><br></div><div>Two llvm_unreachables is overkill. Thankfully we actually have a coding standard for this <<a href="http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations" target="_blank">http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations</a>>.</div>
<div><br></div><div>-- Sean Silva</div><div> </div><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">
/// TranslateX86CC - do a one to one translation of a ISD::CondCode to the X86<br>
/// specific condition code, returning the condition code and the LHS/RHS of the<br>
/// comparison to make.<br>
@@ -9662,6 +9680,17 @@ SDValue X86TargetLowering::EmitCmp(SDVal<br>
SDLoc dl(Op0);<br>
if ((Op0.getValueType() == MVT::i8 || Op0.getValueType() == MVT::i16 ||<br>
Op0.getValueType() == MVT::i32 || Op0.getValueType() == MVT::i64)) {<br>
+ // Do the comparison at i32 if it's smaller. This avoids subregister<br>
+ // aliasing issues. Keep the smaller reference if we're optimizing for<br>
+ // size, however, as that'll allow better folding of memory operations.<br>
+ if (Op0.getValueType() != MVT::i32 && Op0.getValueType() != MVT::i64 &&<br>
+ !DAG.getMachineFunction().getFunction()->getAttributes().hasAttribute(<br>
+ AttributeSet::FunctionIndex, Attribute::MinSize)) {<br>
+ unsigned ExtendOp =<br>
+ isX86CCUnsigned(X86CC) ? ISD::ZERO_EXTEND : ISD::SIGN_EXTEND;<br>
+ Op0 = DAG.getNode(ExtendOp, dl, MVT::i32, Op0);<br>
+ Op1 = DAG.getNode(ExtendOp, dl, MVT::i32, Op1);<br>
+ }<br>
// Use SUB instead of CMP to enable CSE between SUB and CMP.<br>
SDVTList VTs = DAG.getVTList(Op0.getValueType(), MVT::i32);<br>
SDValue Sub = DAG.getNode(X86ISD::SUB, dl, VTs,<br>
<br>
Removed: llvm/trunk/test/CodeGen/X86/2007-10-17-IllegalAsm.ll<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/2007-10-17-IllegalAsm.ll?rev=195495&view=auto" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/2007-10-17-IllegalAsm.ll?rev=195495&view=auto</a><br>
==============================================================================<br>
--- llvm/trunk/test/CodeGen/X86/2007-10-17-IllegalAsm.ll (original)<br>
+++ llvm/trunk/test/CodeGen/X86/2007-10-17-IllegalAsm.ll (removed)<br>
@@ -1,87 +0,0 @@<br>
-; RUN: llc < %s -mtriple=x86_64-linux-gnu | grep addb | not grep x<br>
-; RUN: llc < %s -mtriple=x86_64-linux-gnu | grep cmpb | not grep x<br>
-; PR1734<br>
-<br>
-target triple = "x86_64-unknown-linux-gnu"<br>
- %struct.CUMULATIVE_ARGS = type { i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32 }<br>
- %struct.eh_status = type opaque<br>
- %struct.emit_status = type { i32, i32, %struct.rtx_def*, %struct.rtx_def*, %struct.sequence_stack*, i32, %struct.location_t, i32, i8*, %struct.rtx_def** }<br>
- %struct.expr_status = type { i32, i32, i32, %struct.rtx_def*, %struct.rtx_def*, %struct.rtx_def* }<br>
- %struct.function = type { %struct.eh_status*, %struct.expr_status*, %struct.emit_status*, %struct.varasm_status*, %struct.tree_node*, %struct.tree_node*, %struct.tree_node*, %struct.tree_node*, %struct.function*, i32, i32, i32, i32, %struct.rtx_def*, %struct.CUMULATIVE_ARGS, %struct.rtx_def*, %struct.rtx_def*, %struct.initial_value_struct*, %struct.rtx_def*, %struct.rtx_def*, %struct.rtx_def*, %struct.rtx_def*, %struct.rtx_def*, %struct.rtx_def*, i8, i32, i64, %struct.tree_node*, %struct.tree_node*, %struct.rtx_def*, %struct.varray_head_tag*, %struct.temp_slot*, i32, %struct.var_refs_queue*, i32, i32, %struct.rtvec_def*, %struct.tree_node*, i32, i32, i32, %struct.machine_function*, i32, i32, i8, i8, %struct.language_function*, %struct.rtx_def*, i32, i32, i32, i32, %struct.location_t, %struct.varray_head_tag*, %struct.tree_node*, %struct.tree_node*, i8, i8, i8 }<br>
- %struct.initial_value_struct = type opaque<br>
- %struct.lang_decl = type opaque<br>
- %struct.language_function = type opaque<br>
- %struct.location_t = type { i8*, i32 }<br>
- %struct.machine_function = type { %struct.stack_local_entry*, i8*, %struct.rtx_def*, i32, i32, i32, i32, i32 }<br>
- %struct.rtunion = type { i8* }<br>
- %struct.rtvec_def = type { i32, [1 x %struct.rtx_def*] }<br>
- %struct.rtx_def = type { i16, i8, i8, %struct.u }<br>
- %struct.sequence_stack = type { %struct.rtx_def*, %struct.rtx_def*, %struct.sequence_stack* }<br>
- %struct.stack_local_entry = type opaque<br>
- %struct.temp_slot = type opaque<br>
- %struct.tree_common = type { %struct.tree_node*, %struct.tree_node*, %union.tree_ann_d*, i8, i8, i8, i8, i8 }<br>
- %struct.tree_decl = type { %struct.tree_common, %struct.location_t, i32, %struct.tree_node*, i8, i8, i8, i8, i8, i8, i8, i8, i32, %struct.tree_decl_u1, %struct.tree_node*, %struct.tree_node*, %struct.tree_node*, %struct.tree_node*, %struct.tree_node*, %struct.tree_node*, %struct.tree_node*, %struct.tree_node*, %struct.tree_node*, %struct.tree_node*, %struct.rtx_def*, i32, %struct.tree_decl_u2, %struct.tree_node*, %struct.tree_node*, i64, %struct.lang_decl* }<br>
- %struct.tree_decl_u1 = type { i64 }<br>
- %struct.tree_decl_u2 = type { %struct.function* }<br>
- %struct.tree_node = type { %struct.tree_decl }<br>
- %struct.u = type { [1 x %struct.rtunion] }<br>
- %struct.var_refs_queue = type { %struct.rtx_def*, i32, i32, %struct.var_refs_queue* }<br>
- %struct.varasm_status = type opaque<br>
- %struct.varray_data = type { [1 x i64] }<br>
- %struct.varray_head_tag = type { i64, i64, i32, i8*, %struct.varray_data }<br>
- %union.tree_ann_d = type opaque<br>
-<br>
-define void @layout_type(%struct.tree_node* %type) {<br>
-entry:<br>
- %tmp32 = load i32* null, align 8 ; <i32> [#uses=3]<br>
- %tmp3435 = trunc i32 %tmp32 to i8 ; <i8> [#uses=1]<br>
- %tmp53 = icmp eq %struct.tree_node* null, null ; <i1> [#uses=1]<br>
- br i1 %tmp53, label %cond_next57, label %UnifiedReturnBlock<br>
-<br>
-cond_next57: ; preds = %entry<br>
- %tmp65 = and i32 %tmp32, 255 ; <i32> [#uses=1]<br>
- switch i32 %tmp65, label %UnifiedReturnBlock [<br>
- i32 6, label %bb140<br>
- i32 7, label %bb140<br>
- i32 8, label %bb140<br>
- i32 13, label %bb478<br>
- ]<br>
-<br>
-bb140: ; preds = %cond_next57, %cond_next57, %cond_next57<br>
- %tmp219 = load i32* null, align 8 ; <i32> [#uses=1]<br>
- %tmp221222 = trunc i32 %tmp219 to i8 ; <i8> [#uses=1]<br>
- %tmp223 = icmp eq i8 %tmp221222, 24 ; <i1> [#uses=1]<br>
- br i1 %tmp223, label %cond_true226, label %cond_next340<br>
-<br>
-cond_true226: ; preds = %bb140<br>
- switch i8 %tmp3435, label %cond_true288 [<br>
- i8 6, label %cond_next340<br>
- i8 9, label %cond_next340<br>
- i8 7, label %cond_next340<br>
- i8 8, label %cond_next340<br>
- i8 10, label %cond_next340<br>
- ]<br>
-<br>
-cond_true288: ; preds = %cond_true226<br>
- unreachable<br>
-<br>
-cond_next340: ; preds = %cond_true226, %cond_true226, %cond_true226, %cond_true226, %cond_true226, %bb140<br>
- ret void<br>
-<br>
-bb478: ; preds = %cond_next57<br>
- br i1 false, label %cond_next500, label %cond_true497<br>
-<br>
-cond_true497: ; preds = %bb478<br>
- unreachable<br>
-<br>
-cond_next500: ; preds = %bb478<br>
- %tmp513 = load i32* null, align 8 ; <i32> [#uses=1]<br>
- %tmp545 = and i32 %tmp513, 8192 ; <i32> [#uses=1]<br>
- %tmp547 = and i32 %tmp32, -8193 ; <i32> [#uses=1]<br>
- %tmp548 = or i32 %tmp547, %tmp545 ; <i32> [#uses=1]<br>
- store i32 %tmp548, i32* null, align 8<br>
- ret void<br>
-<br>
-UnifiedReturnBlock: ; preds = %cond_next57, %entry<br>
- ret void<br>
-}<br>
<br>
Modified: llvm/trunk/test/CodeGen/X86/3addr-16bit.ll<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/3addr-16bit.ll?rev=195496&r1=195495&r2=195496&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/3addr-16bit.ll?rev=195496&r1=195495&r2=195496&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/test/CodeGen/X86/3addr-16bit.ll (original)<br>
+++ llvm/trunk/test/CodeGen/X86/3addr-16bit.ll Fri Nov 22 13:57:47 2013<br>
@@ -34,7 +34,7 @@ entry:<br>
<br>
; 64BIT-LABEL: t2:<br>
; 64BIT-NOT: movw %si, %ax<br>
-; 64BIT: decl %eax<br>
+; 64BIT: leal -1(%rsi), %eax<br>
; 64BIT: movzwl %ax<br>
%0 = icmp eq i16 %k, %c ; <i1> [#uses=1]<br>
%1 = add i16 %k, -1 ; <i16> [#uses=3]<br>
@@ -59,7 +59,7 @@ entry:<br>
<br>
; 64BIT-LABEL: t3:<br>
; 64BIT-NOT: movw %si, %ax<br>
-; 64BIT: addl $2, %eax<br>
+; 64BIT: leal 2(%rsi), %eax<br>
%0 = add i16 %k, 2 ; <i16> [#uses=3]<br>
%1 = icmp eq i16 %k, %c ; <i1> [#uses=1]<br>
br i1 %1, label %bb, label %bb1<br>
@@ -82,7 +82,7 @@ entry:<br>
<br>
; 64BIT-LABEL: t4:<br>
; 64BIT-NOT: movw %si, %ax<br>
-; 64BIT: addl %edi, %eax<br>
+; 64BIT: leal (%rsi,%rdi), %eax<br>
%0 = add i16 %k, %c ; <i16> [#uses=3]<br>
%1 = icmp eq i16 %k, %c ; <i1> [#uses=1]<br>
br i1 %1, label %bb, label %bb1<br>
<br>
Modified: llvm/trunk/test/CodeGen/X86/codegen-prepare-extload.ll<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/codegen-prepare-extload.ll?rev=195496&r1=195495&r2=195496&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/codegen-prepare-extload.ll?rev=195496&r1=195495&r2=195496&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/test/CodeGen/X86/codegen-prepare-extload.ll (original)<br>
+++ llvm/trunk/test/CodeGen/X86/codegen-prepare-extload.ll Fri Nov 22 13:57:47 2013<br>
@@ -5,7 +5,7 @@<br>
; CodeGenPrepare should move the zext into the block with the load<br>
; so that SelectionDAG can select it with the load.<br>
<br>
-; CHECK: movzbl ({{%rdi|%rcx}}), %eax<br>
+; CHECK: movsbl ({{%rdi|%rcx}}), %eax<br>
<br>
define void @foo(i8* %p, i32* %q) {<br>
entry:<br>
<br>
Modified: llvm/trunk/test/CodeGen/X86/ctpop-combine.ll<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/ctpop-combine.ll?rev=195496&r1=195495&r2=195496&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/ctpop-combine.ll?rev=195496&r1=195495&r2=195496&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/test/CodeGen/X86/ctpop-combine.ll (original)<br>
+++ llvm/trunk/test/CodeGen/X86/ctpop-combine.ll Fri Nov 22 13:57:47 2013<br>
@@ -35,6 +35,6 @@ define i32 @test3(i64 %x) nounwind readn<br>
%conv = zext i1 %cmp to i32<br>
ret i32 %conv<br>
; CHECK-LABEL: test3:<br>
-; CHECK: cmpb $2<br>
+; CHECK: cmpl $2<br>
; CHECK: ret<br>
}<br>
<br>
Modified: llvm/trunk/test/CodeGen/X86/memcmp.ll<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/memcmp.ll?rev=195496&r1=195495&r2=195496&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/memcmp.ll?rev=195496&r1=195495&r2=195496&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/test/CodeGen/X86/memcmp.ll (original)<br>
+++ llvm/trunk/test/CodeGen/X86/memcmp.ll Fri Nov 22 13:57:47 2013<br>
@@ -22,8 +22,9 @@ bb:<br>
return: ; preds = %entry<br>
ret void<br>
; CHECK-LABEL: memcmp2:<br>
-; CHECK: movw ([[A0:%rdi|%rcx]]), %ax<br>
-; CHECK: cmpw ([[A1:%rsi|%rdx]]), %ax<br>
+; CHECK: movzwl<br>
+; CHECK-NEXT: movzwl<br>
+; CHECK-NEXT: cmpl<br>
; NOBUILTIN-LABEL: memcmp2:<br>
; NOBUILTIN: callq<br>
}<br>
@@ -41,7 +42,8 @@ bb:<br>
return: ; preds = %entry<br>
ret void<br>
; CHECK-LABEL: memcmp2a:<br>
-; CHECK: cmpw $28527, ([[A0]])<br>
+; CHECK: movzwl<br>
+; CHECK-NEXT: cmpl $28527,<br>
}<br>
<br>
<br>
@@ -58,8 +60,8 @@ bb:<br>
return: ; preds = %entry<br>
ret void<br>
; CHECK-LABEL: memcmp4:<br>
-; CHECK: movl ([[A0]]), %eax<br>
-; CHECK: cmpl ([[A1]]), %eax<br>
+; CHECK: movl<br>
+; CHECK-NEXT: cmpl<br>
}<br>
<br>
define void @memcmp4a(i8* %X, i32* nocapture %P) nounwind {<br>
@@ -75,7 +77,7 @@ bb:<br>
return: ; preds = %entry<br>
ret void<br>
; CHECK-LABEL: memcmp4a:<br>
-; CHECK: cmpl $1869573999, ([[A0]])<br>
+; CHECK: cmpl $1869573999,<br>
}<br>
<br>
define void @memcmp8(i8* %X, i8* %Y, i32* nocapture %P) nounwind {<br>
@@ -91,8 +93,8 @@ bb:<br>
return: ; preds = %entry<br>
ret void<br>
; CHECK-LABEL: memcmp8:<br>
-; CHECK: movq ([[A0]]), %rax<br>
-; CHECK: cmpq ([[A1]]), %rax<br>
+; CHECK: movq<br>
+; CHECK: cmpq<br>
}<br>
<br>
define void @memcmp8a(i8* %X, i32* nocapture %P) nounwind {<br>
@@ -108,7 +110,7 @@ bb:<br>
return: ; preds = %entry<br>
ret void<br>
; CHECK-LABEL: memcmp8a:<br>
-; CHECK: movabsq $8029759185026510694, %rax<br>
-; CHECK: cmpq %rax, ([[A0]])<br>
+; CHECK: movabsq $8029759185026510694,<br>
+; CHECK: cmpq<br>
}<br>
<br>
<br>
Modified: llvm/trunk/test/CodeGen/X86/shrink-compare.ll<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/shrink-compare.ll?rev=195496&r1=195495&r2=195496&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/shrink-compare.ll?rev=195496&r1=195495&r2=195496&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/test/CodeGen/X86/shrink-compare.ll (original)<br>
+++ llvm/trunk/test/CodeGen/X86/shrink-compare.ll Fri Nov 22 13:57:47 2013<br>
@@ -2,7 +2,7 @@<br>
<br>
declare void @bar()<br>
<br>
-define void @test1(i32* nocapture %X) nounwind {<br>
+define void @test1(i32* nocapture %X) nounwind minsize {<br>
entry:<br>
%tmp1 = load i32* %X, align 4<br>
%and = and i32 %tmp1, 255<br>
@@ -19,7 +19,7 @@ if.end:<br>
; CHECK: cmpb $47, (%{{rdi|rcx}})<br>
}<br>
<br>
-define void @test2(i32 %X) nounwind {<br>
+define void @test2(i32 %X) nounwind minsize {<br>
entry:<br>
%and = and i32 %X, 255<br>
%cmp = icmp eq i32 %and, 47<br>
@@ -35,7 +35,7 @@ if.end:<br>
; CHECK: cmpb $47, %{{dil|cl}}<br>
}<br>
<br>
-define void @test3(i32 %X) nounwind {<br>
+define void @test3(i32 %X) nounwind minsize {<br>
entry:<br>
%and = and i32 %X, 255<br>
%cmp = icmp eq i32 %and, 255<br>
@@ -70,7 +70,7 @@ lor.end:<br>
@x = global { i8, i8, i8, i8, i8, i8, i8, i8 } { i8 1, i8 0, i8 0, i8 0, i8 1, i8 0, i8 0, i8 1 }, align 4<br>
<br>
; PR16551<br>
-define void @test5(i32 %X) nounwind {<br>
+define void @test5(i32 %X) nounwind minsize {<br>
entry:<br>
%bf.load = load i56* bitcast ({ i8, i8, i8, i8, i8, i8, i8, i8 }* @x to i56*), align 4<br>
%bf.lshr = lshr i56 %bf.load, 32<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br></div></div>
</blockquote></div></div></div><br></div></blockquote></div><br></div></div>