<div dir="ltr"><div>Hi Sergey,</div><div><br></div><div>I got the following performance result for running time on cortex-A57,</div><div><br></div><div>spec.cpu2000.ref.176_gcc<span class="" style="white-space:pre"> </span>1.11%</div>
<div>spec.cpu2000.ref.177_mesa<span class="" style="white-space:pre"> </span>2.09%</div><div>spec.cpu2000.ref.179_art<span class="" style="white-space:pre"> </span>2.10%</div><div>spec.cpu2000.ref.254_gap<span class="" style="white-space:pre"> </span>1.27%</div>
<div>spec.cpu2000.ref.256_bzip2<span class="" style="white-space:pre"> </span>2.80%</div><div>spec.cpu2006.ref.401_bzip2<span class="" style="white-space:pre"> </span>1.50%</div><div>spec.cpu2006.ref.403_gcc<span class="" style="white-space:pre"> </span>2.54%</div>
<div>spec.cpu2006.ref.453_povray<span class="" style="white-space:pre"> </span>2.60%</div><div>spec.cpu2006.ref.456_hmmer<span class="" style="white-space:pre"> </span>1.58%</div><div><br></div><div>spec.cpu2000.ref.186_crafty<span class="" style="white-space:pre"> </span>-2.65%</div>
<div>spec.cpu2000.ref.197_parser<span class="" style="white-space:pre"> </span>-1.32%</div><div>spec.cpu2006.ref.400_perlbench<span class="" style="white-space:pre"> </span>-1.73%</div><div>spec.cpu2006.ref.433_milc<span class="" style="white-space:pre"> </span>-2.49%</div>
<div>spec.cpu2006.ref.464_h264ref<span class="" style="white-space:pre"> </span>-1.34%</div><div><br></div><div>So it looks we have larger number of regressions than improvements on spec benchmark.</div><div><br></div><div>
For 256.bzip2, I find a lot of cases of comparing with constant 1, so finally the code like below in function hbMakeCodeLengths,</div><div><br></div><div><div>subs<span class="" style="white-space:pre"> </span>w12, w2, #0x1</div>
<div><a href="http://b.lt">b.lt</a><span class="" style="white-space:pre"> </span>988 <hbMakeCodeLengths+0xd0></div></div><div><br></div><div>your patch will transform it into </div><div><br></div><div><div>cmp<span class="" style="white-space:pre"> </span>w2, #0x0</div>
<div>b.le<span class="" style="white-space:pre"> </span>98c <hbMakeCodeLengths+0xd4></div><div>sub<span class="" style="white-space:pre"> </span>w12, w2, #0x1</div></div><div><br></div><div>I'm not sure this is the root cause of regression, but obviously this change is not a good one.</div>
<div><br></div><div>Could you please have a look?</div><div><br></div><div>Thanks,</div><div>-Jiangning</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-31 9:55 GMT+08:00 Jiangning Liu <span dir="ltr"><<a href="mailto:liujiangning1@gmail.com" target="_blank">liujiangning1@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Sergey,<div><br></div><div>I noticed a lot of code changes for spec2000/256.bzip2 after applying your patch, so I'd like to see the performance impact before committing the code.</div>
<div><br></div><div>
Thanks,</div><div>-Jiangning</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-30 15:25 GMT+08:00 Sergey Dmitrouk <span dir="ltr"><<a href="mailto:sdmitrouk@accesssoftek.com" target="_blank">sdmitrouk@accesssoftek.com</a>></span>:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jiangning,<br>
<br>
Great! Could you please commit the patch? I don't have write access.<br>
<br>
Thanks,<br>
Sergey<br>
<div><br>
On Tue, Jul 29, 2014 at 06:37:09PM -0700, Jiangning Liu wrote:<br>
> Hi Sergey,<br>
</div><div>> Looks good to me now!<br>
> Thanks,<br>
> -Jiangning<br>
><br>
> 2014-07-29 17:51 GMT+08:00 Sergey Dmitrouk <<a href="mailto:sdmitrouk@accesssoftek.com" target="_blank">sdmitrouk@accesssoftek.com</a>>:<br>
><br>
> Hi Jiangning,<br>
> > I think it would be better if you can simply check sequential b.xx<br>
> > instructions like,<br>
><br>
> Thanks, updated that, I though it won't be changed as "lor.lhs.false" is<br>
> in the .ll file.<br>
> > I found your patch would trigger two failures for llvm regression<br>
> test,<br>
> > test/CodeGen/AArch64/arm64-ccmp.ll<br>
> > test/CodeGen/AArch64/arm64-cse.ll<br>
> > Have you tried that?<br>
><br>
> Sorry, I did run all test before, but maybe failed to do this with<br>
> correct<br>
> version of llc binary.<br>
><br>
> "test/CodeGen/AArch64/arm64-ccmp.ll" required a small update in<br>
> conditional check, which doesn't seem to affect anything.<br>
><br>
> "test/CodeGen/AArch64/arm64-cse.ll" explicitly checks for old behaviour<br>
> and<br>
</div>> assumes comparison with 1. A Modified to perform two separate checks:<br>
> A 1. No CSE for that case when comparing with 1.<br>
> A 2. CSE for all other cases.<br>
> It seems to be fine as comparison with zero should be more frequent. A I<br>
<div>> guess we can't support both kinds of optimizations at the same time.<br>
><br>
> By the way, thanks for you patience.<br>
><br>
> Cheers,<br>
> Sergey<br>
> On Mon, Jul 28, 2014 at 09:32:40PM -0700, Jiangning Liu wrote:<br>
</div>> > A A Hi Sergey,<br>
> > A A I found your patch would trigger two failures for llvm regression<br>
> test,<br>
> > A A test/CodeGen/AArch64/arm64-ccmp.ll<br>
> > A A test/CodeGen/AArch64/arm64-cse.ll<br>
> > A A Have you tried that?<br>
<div>> > A A Thanks,<br>
> > A A -Jiangning<br>
> ><br>
</div>> > A A 2014-07-29 10:02 GMT+08:00 Jiangning Liu<br>
> <<a href="mailto:liujiangning1@gmail.com" target="_blank">liujiangning1@gmail.com</a>>:<br>
> ><br>
<div>> > A A A Hi Sergey,<br>
</div>> > A A A I just noticed your test case is checking the "comment" in<br>
> assembly<br>
> > A A A code. I think it would be better if you can simply check<br>
> sequential b.xx<br>
> > A A A instructions like,<br>
> > A A A ; CHECK: cmp<br>
> > A A A ; CHECK: <a href="http://b.lt" target="_blank">b.lt</a><br>
> > A A A ; CHECK-NOT: cmp<br>
> > A A A ; CHECK: b.le<br>
> > A A A This way the test can be more stable, because the internal<br>
> symbol like<br>
> > A A A %lor.lhs.false can be easily changed from time to time.<br>
> > A A A Thanks,<br>
> > A A A -Jiangning<br>
> ><br>
> > A A A 2014-07-28 16:40 GMT+08:00 Sergey Dmitrouk<br>
> <<a href="mailto:sdmitrouk@accesssoftek.com" target="_blank">sdmitrouk@accesssoftek.com</a>>:<br>
> ><br>
> > A A A A Hi Jiangning,<br>
> ><br>
> > A A A A You're right, I just thought it might make sense to leave a<br>
> chance of<br>
> > A A A A catching illegal immediate values after optimizations,<br>
> which is<br>
> > A A A A actually<br>
> > A A A A not something to consider in this case with one and zero.<br>
> ><br>
> > A A A A Also, maybe<br>
> ><br>
> > A A A A A A A A C = (RHS.getValueType() == MVT::i32) ? (uint32_t)(C<br>
> - 1) : (C -<br>
> > A A A A 1);<br>
> ><br>
> > A A A A worth changing to<br>
> ><br>
> > A A A A A A A A C = 0ULL;<br>
> ><br>
> > A A A A It's left from my tries to generalize optimization, but it<br>
> might be<br>
> > A A A A useful if someone will add additional condition.<br>
<div>> ><br>
> > A A A A Thanks,<br>
</div><div>> > A A A A Sergey<br>
</div>> > A A A A On Sun, Jul 27, 2014 at 10:30:45PM -0700, Jiangning Liu<br>
<div>> wrote:<br>
> > A A A A > A A A Hi Sergey,<br>
</div>> > A A A A > A A A Would it be more clear on logic if you move that<br>
> piece of code<br>
> > A A A A to be<br>
> > A A A A > A A A inside the else branch of "if<br>
> (!isLegalArithImmed(C)) { ... }<br>
> > A A A A else {...}"?<br>
> > A A A A > A A A I think it would be clear that (C==1) is legal, but<br>
> we still<br>
> > A A A A want to<br>
> > A A A A > A A A optimize it, and any more optimization cases<br>
> falling into<br>
> > A A A A "legal" scenario<br>
> > A A A A > A A A would be easily added in future.<br>
> > A A A A > A A A I will be OK if you can simply make this change.<br>
<div>> > A A A A > A A A Thanks,<br>
> > A A A A > A A A -Jiangning<br>
> > A A A A ><br>
</div>> > A A A A > A A A 2014-07-25 15:21 GMT+08:00 Sergey Dmitrouk<br>
<div>> > A A A A <<a href="mailto:sdmitrouk@accesssoftek.com" target="_blank">sdmitrouk@accesssoftek.com</a>>:<br>
> > A A A A ><br>
</div>> > A A A A > A A A A A Hi Jiangning,<br>
> > A A A A > A A A A A > Did you forget to attach your new patch?<br>
> > A A A A ><br>
> > A A A A > A A A A A Yes, sorry for that. A It's attached now.<br>
> > A A A A > A A A A A > Hopefully we can understand why this could<br>
> happen, but<br>
> > A A A A maybe this is<br>
> > A A A A > A A A A A just<br>
> > A A A A > A A A A A > a heuristic result depending on the real<br>
> control flow and<br>
> > A A A A workload.<br>
> > A A A A ><br>
> > A A A A > A A A A A As that code is common for all supported<br>
> architectures,<br>
> > A A A A maybe it is<br>
> > A A A A > A A A A A important for only some of them and doesn't<br>
> cause<br>
> > A A A A significant<br>
> > A A A A > A A A A A performance<br>
> > A A A A > A A A A A changes for others?<br>
<div>> > A A A A ><br>
> > A A A A > A A A A A Best regards,<br>
> > A A A A > A A A A A Sergey<br>
</div>> > A A A A > A A A A A On Thu, Jul 24, 2014 at 07:05:43PM -0700,<br>
> Jiangning Liu<br>
> > A A A A wrote:<br>
> > A A A A > A A A A A > A A A Hi Sergey,<br>
> > A A A A > A A A A A > A A A Did you forget to attach your new<br>
> patch?<br>
> > A A A A > A A A A A > A A A I tried the spec benchmarks by<br>
> disabling that code<br>
> > A A A A of inverting<br>
> > A A A A > A A A A A the<br>
> > A A A A > A A A A A > A A A condition, and only see the following<br>
> performance<br>
> > A A A A changes and no<br>
> > A A A A > A A A A A change<br>
> > A A A A > A A A A A > A A A for all others.<br>
> > A A A A > A A A A A > A A A 164.gzip (ref) A +1.76%<br>
> > A A A A > A A A A A > A A A 458.sjeng (train) + 2.19%<br>
> > A A A A > A A A A A > A A A 471.omnetpp (train) -1.43%<br>
> > A A A A > A A A A A > A A A 473.astar (train) -1.51%<br>
> > A A A A > A A A A A > A A A Hopefully we can understand why this<br>
> could happen,<br>
> > A A A A but maybe this<br>
> > A A A A > A A A A A is just<br>
> > A A A A > A A A A A > A A A a heuristic result depending on the<br>
> real control<br>
> > A A A A flow and<br>
> > A A A A > A A A A A workload.<br>
> > A A A A > A A A A A > A A A Thanks,<br>
> > A A A A > A A A A A > A A A -Jiangning<br>
<div>> > A A A A > A A A A A ><br>
</div>> > A A A A > A A A A A > A A A 2014-07-24 16:17 GMT+08:00 Sergey<br>
> Dmitrouk<br>
> > A A A A > A A A A A <<a href="mailto:sdmitrouk@accesssoftek.com" target="_blank">sdmitrouk@accesssoftek.com</a>>:<br>
<div>> > A A A A > A A A A A ><br>
</div>> > A A A A > A A A A A > A A A A A Hello Jiangning,<br>
<div>> > A A A A > A A A A A ><br>
</div>> > A A A A > A A A A A > A A A A A Thanks for your comments.<br>
<div>> > A A A A > A A A A A ><br>
</div>> > A A A A > A A A A A > A A A A A > 1) I expect the fix should be<br>
> insideA<br>
> > A A A A getAArch64Cmp.<br>
> > A A A A > A A A A A > A A A A A >...<br>
> > A A A A > A A A A A > A A A A A > but essentially getAArch64Cmp<br>
> missed the case<br>
<div>> > A A A A of (x < 1) -><br>
</div>> > A A A A > A A A A A (x <= 0).<br>
<div>> > A A A A > A A A A A ><br>
</div>> > A A A A > A A A A A > A A A A A It was initial placement of the<br>
> fix, but the<br>
> > A A A A function doesn't<br>
> > A A A A > A A A A A seem to<br>
> > A A A A > A A A A A > A A A A A perform transformations like that.<br>
> A It updates<br>
> > A A A A conditions<br>
> > A A A A > A A A A A only when<br>
> > A A A A > A A A A A > A A A A A immediate values are not legal. A<br>
> There is no<br>
> > A A A A comment for the<br>
> > A A A A > A A A A A function,<br>
> > A A A A > A A A A A > A A A A A so I'm not sure whether such checks<br>
> fit there,<br>
> > A A A A but I moved the<br>
> > A A A A > A A A A A change.<br>
> > A A A A > A A A A A > A A A A A > 2) Your comment is inconsistent<br>
> with your<br>
> > A A A A code.<br>
<div>> > A A A A > A A A A A ><br>
</div>> > A A A A > A A A A A > A A A A A Thanks, it's probably because of<br>
> inverted<br>
> > A A A A conditions in DAGs.<br>
> > A A A A > A A A A A > A A A A A > So now I'm wondering how to<br>
> justify this is<br>
> > A A A A always<br>
> > A A A A > A A A A A meaningful for<br>
> > A A A A > A A A A A > A A A A A AArch64?<br>
<div>> > A A A A > A A A A A ><br>
</div>> > A A A A > A A A A A > A A A A A I wasn't sure whether it's worth<br>
> such change,<br>
> > A A A A but as an option<br>
> > A A A A > A A A A A something<br>
> > A A A A > A A A A A > A A A A A like<br>
> > A A A A TargetLowering::isInversionBeneficial(SDValue Cond) can<br>
> > A A A A > A A A A A be added,<br>
> > A A A A > A A A A A > A A A A A but I don't know whether it's<br>
> possible to check<br>
> > A A A A for conditions<br>
> > A A A A > A A A A A like<br>
> > A A A A > A A A A A > A A A A A "(a < 0 && b == c || a > 0 && b ==<br>
> d)" to do not<br>
> > A A A A block<br>
> > A A A A > A A A A A inversion for all<br>
> > A A A A > A A A A A > A A A A A cases.<br>
<div>> > A A A A > A A A A A ><br>
</div>> > A A A A > A A A A A > A A A A A Attached updated patch at least to<br>
> see whether<br>
> > A A A A the fix fits<br>
> > A A A A > A A A A A well in<br>
> > A A A A > A A A A A > A A A A A getAArch64Cmp().<br>
<div>> > A A A A > A A A A A ><br>
</div>> > A A A A > A A A A A > A A A A A Regards,<br>
> > A A A A > A A A A A > A A A A A Sergey<br>
> > A A A A > A A A A A > A A A A A On Wed, Jul 23, 2014 at 10:05:37PM<br>
> -0700,<br>
> > A A A A Jiangning Liu wrote:<br>
> > A A A A > A A A A A > A A A A A > A A A Hi Sergey,<br>
> > A A A A > A A A A A > A A A A A > A A A 1) I expect the fix should<br>
> be insideA<br>
> > A A A A getAArch64Cmp.<br>
> > A A A A > A A A A A > A A A A A > A A A 2) Your comment is<br>
> inconsistent with<br>
> > A A A A your code. Your<br>
> > A A A A > A A A A A code is to<br>
> > A A A A > A A A A A > A A A A A transform<br>
> > A A A A > A A A A A > A A A A A > A A A (x < 1) to be (x<=0),<br>
> rather than "Turn<br>
> > A A A A "x > 1"<br>
> > A A A A > A A A A A condition into "x<br>
> > A A A A > A A A A A > A A A A A >= 0"".<br>
> > A A A A > A A A A A > A A A A A > A A A I also noticed we have the<br>
> following<br>
> > A A A A transformation<br>
> > A A A A > A A A A A for if<br>
> > A A A A > A A A A A > A A A A A condition (x <<br>
> > A A A A > A A A A A > A A A A A > A A A 0) in back-end,<br>
> > A A A A > A A A A A > A A A A A > A A A stage 1: (x < 0) -> (x >=<br>
> 0), i.e. (x<0)<br>
> > A A A A and invert<br>
> > A A A A > A A A A A the targets.<br>
> > A A A A > A A A A A > A A A A A > A A A stage 2: (x >= 0) -> (x ><br>
> -1). This<br>
> > A A A A happens in<br>
> > A A A A > A A A A A combine1.<br>
> > A A A A > A A A A A > A A A A A > A A A stage 3: (x > -1) -> (x >=<br>
> 0) in<br>
> > A A A A getAArch64Cmp.<br>
> > A A A A > A A A A A > A A A A A > A A A For if condition (x > 0),<br>
> the<br>
> > A A A A transformation is<br>
> > A A A A > A A A A A similar. Your<br>
> > A A A A > A A A A A > A A A A A patch is<br>
> > A A A A > A A A A A > A A A A A > A A A trying to cover this case,<br>
> but<br>
> > A A A A essentially<br>
> > A A A A > A A A A A getAArch64Cmp missed<br>
> > A A A A > A A A A A > A A A A A the case<br>
> > A A A A > A A A A A > A A A A A > A A A of (x < 1) -> (x <= 0).<br>
> > A A A A > A A A A A > A A A A A > A A A However, as you can see the<br>
> root cause<br>
> > A A A A of generating<br>
> > A A A A > A A A A A the<br>
> > A A A A > A A A A A > A A A A A comparison with<br>
> > A A A A > A A A A A > A A A A A > A A A constant 1 is stage 1. This<br>
> happens<br>
> > A A A A > A A A A A > A A A A A > A A A insideA<br>
> > A A A A SelectionDAGBuilder::visitSwitchCase<br>
> > A A A A > A A A A A > A A A A A > A A A A A // If the lhs block is<br>
> the next<br>
> > A A A A block, invert the<br>
> > A A A A > A A A A A condition<br>
> > A A A A > A A A A A > A A A A A so that we<br>
> > A A A A > A A A A A > A A A A A > A A A can<br>
> > A A A A > A A A A A > A A A A A > A A A A A // fall through to the<br>
> lhs instead<br>
> > A A A A of the rhs<br>
> > A A A A > A A A A A block.<br>
> > A A A A > A A A A A > A A A A A > A A A A A if (CB.TrueBB ==<br>
> NextBlock) {<br>
> > A A A A > A A A A A > A A A A A > A A A A A A A<br>
> std::swap(CB.TrueBB,<br>
> > A A A A CB.FalseBB);<br>
> > A A A A > A A A A A > A A A A A > A A A A A A A SDValue True =<br>
> > A A A A DAG.getConstant(1,<br>
> > A A A A > A A A A A Cond.getValueType());<br>
> > A A A A > A A A A A > A A A A A > A A A A A A A Cond =<br>
> DAG.getNode(ISD::XOR, dl,<br>
> > A A A A > A A A A A Cond.getValueType(),<br>
> > A A A A > A A A A A > A A A A A Cond, True);<br>
<div>> > A A A A > A A A A A > A A A A A > A A A A A }<br>
> > A A A A > A A A A A > A A A A A > A A A So now I'm wondering how to<br>
> justify this<br>
</div>> > A A A A is always<br>
> > A A A A > A A A A A meaningful for<br>
> > A A A A > A A A A A > A A A A A AArch64?<br>
> > A A A A > A A A A A > A A A A A > A A A Thanks,<br>
> > A A A A > A A A A A > A A A A A > A A A -Jiangning<br>
<div>> > A A A A > A A A A A > A A A A A ><br>
> > A A A A > A A A A A > A A A A A > A A A 2014-07-23 23:54 GMT+08:00<br>
> Sergey<br>
</div>> > A A A A Dmitrouk<br>
> > A A A A > A A A A A > A A A A A <<a href="mailto:sdmitrouk@accesssoftek.com" target="_blank">sdmitrouk@accesssoftek.com</a>>:<br>
<div>> > A A A A > A A A A A > A A A A A ><br>
> > A A A A > A A A A A > A A A A A > A A A A A Hi,<br>
> > A A A A > A A A A A > A A A A A ><br>
> > A A A A > A A A A A > A A A A A > A A A A A Basing on the following<br>
> information<br>
</div>> > A A A A from [this<br>
> > A A A A > A A A A A post][0] by<br>
> > A A A A > A A A A A > A A A A A James Molloy:<br>
<div>> > A A A A > A A A A A > A A A A A ><br>
> > A A A A > A A A A A > A A A A A > A A A A A A A 2. "if (a < 0 && b<br>
> == c || a > 0<br>
</div>> > A A A A && b == d)" -<br>
> > A A A A > A A A A A the first<br>
> > A A A A > A A A A A > A A A A A comparison<br>
> > A A A A > A A A A A > A A A A A > A A A A A of<br>
> > A A A A > A A A A A > A A A A A > A A A A A A A 'a' against zero is<br>
> done twice,<br>
> > A A A A when the flag<br>
> > A A A A > A A A A A results of<br>
> > A A A A > A A A A A > A A A A A the first<br>
> > A A A A > A A A A A > A A A A A > A A A A A A A comparison could be<br>
> used for the<br>
> > A A A A second<br>
> > A A A A > A A A A A comparison.<br>
<div>> > A A A A > A A A A A > A A A A A ><br>
> > A A A A > A A A A A > A A A A A > A A A A A I've made a patch<br>
> (attached) that<br>
</div>> > A A A A removes this<br>
> > A A A A > A A A A A extra<br>
> > A A A A > A A A A A > A A A A A comparison. A More<br>
> > A A A A > A A A A A > A A A A A > A A A A A complex cases like<br>
> comparisons with<br>
> > A A A A non-zero<br>
> > A A A A > A A A A A immediate values<br>
> > A A A A > A A A A A > A A A A A or with<br>
> > A A A A > A A A A A > A A A A A > A A A A A registers doesn't seem<br>
> to be task<br>
> > A A A A for a code<br>
> > A A A A > A A A A A generator. A<br>
> > A A A A > A A A A A > A A A A A Comparing with<br>
> > A A A A > A A A A A > A A A A A > A A A A A zero is quite common,<br>
> so I seems to<br>
> > A A A A be worth<br>
> > A A A A > A A A A A adding.<br>
<div>> > A A A A > A A A A A > A A A A A ><br>
> > A A A A > A A A A A > A A A A A > A A A A A Please review the<br>
> patch. A Couldn't<br>
</div>> > A A A A find a better<br>
> > A A A A > A A A A A place to<br>
> > A A A A > A A A A A > A A A A A make the<br>
> > A A A A > A A A A A > A A A A A > A A A A A change, but I'll be<br>
> happy to adjust<br>
> > A A A A the patch if<br>
> > A A A A > A A A A A anyone has<br>
> > A A A A > A A A A A > A A A A A better<br>
> > A A A A > A A A A A > A A A A A > A A A A A ideas.<br>
<div>> > A A A A > A A A A A > A A A A A ><br>
> > A A A A > A A A A A > A A A A A > A A A A A Best regards,<br>
</div>> > A A A A > A A A A A > A A A A A > A A A A A Sergey<br>
<div>> > A A A A > A A A A A > A A A A A ><br>
> > A A A A > A A A A A > A A A A A > A A A A A 0:<br>
</div>> > A A A A > A A A A A > A A A A A<br>
> > A A A<br>
> A <a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/74269" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.devel/74269</a><br>
<div>> > A A A A > A A A A A > A A A A A ><br>
</div>> > A A A A > A A A A A > A A A A A > A A A A A<br>
<div>> > A A A A _______________________________________________<br>
</div>> > A A A A > A A A A A > A A A A A > A A A A A llvm-commits mailing<br>
> list<br>
> > A A A A > A A A A A > A A A A A > A A A A A<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
> > A A A A > A A A A A > A A A A A > A A A A A<br>
<div><div>> > A A A A > A A A A 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>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div><br></div>