<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class="">- Dave</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jul 21, 2016 at 7:02 PM Pete Cooper <<a href="mailto:peter_cooper@apple.com" class="">peter_cooper@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Sorry David, I let this slip by then was on vacation.<div class=""><br class=""></div><div class="">Your patch worked much better than mine. I fixed one of the - operators which was the wrong way around, but otherwise the logic is the same as your path.</div><div class=""><br class=""></div><div class="">I also added tests which should hit every method added and checks all of the getRawData()’s as you suggested was possible.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Pete</div><div class=""><br class=""></div><div class=""></div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""></blockquote></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 6, 2016, at 3:59 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> wrote:</div><br class="m_-1547713625398307004Apple-interchange-newline"></blockquote></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><br class="m_-1547713625398307004Apple-interchange-newline">On Sun, Jun 5, 2016 at 11:55 AM, Pete Cooper<span class="m_-1547713625398307004Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:peter_cooper@apple.com" target="_blank" class="">peter_cooper@apple.com</a>></span><span class="m_-1547713625398307004Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jun 4, 2016, at 9:10 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Looks like you just have a variable rename in the unary minus implementation - commit separately or drop that change perhaps?<br class=""></div></div></blockquote></span>Oh yeah. Good catch. Will do that separately.<span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class="">I don't think you need versions that take two rvalue refs (+(&&, &&)), is there? (until +=/-= get smart and have an overload that takes an rvalue ref parameter and uses it to steal the right hand side buffer if it's bigger than the left hand side buffer or something like that?)<br class=""></div></div></blockquote></span>I had a compile error somewhere in the LLVM codebase without this version. I can’t remember where it is, but a small test (attached to the end of the email if you want to hack on it) which triggers it is:</div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">rvalue.cpp:66:22: error: use of overloaded operator '+' is ambiguous (with operand types 'APInt' and 'APInt')</div><div class=""> APInt d2 = (a * b) + (a * b);</div><div class=""><br class=""></div></blockquote><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class="">& can you pass by value instead of by rvalue ref - does that work/choose the right overloads?<br class=""></div></div></blockquote></span>Doesn’t seem to. Using the above as an example, if I remove the && from both arguments then I get:</div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">rvalue.cpp:72:22: error: use of overloaded operator '+' is ambiguous (with operand types 'APInt' and 'APInt')</div><div class=""> APInt d2 = (a * b) + (a * b);</div><div class=""> ~~~~~~~ ^ ~~~~~~~</div><div class="">rvalue.cpp:35:14: note: candidate function</div><div class="">inline APInt operator+(APInt a, APInt b) {</div><div class=""> ^</div><div class="">rvalue.cpp:41:14: note: candidate function</div><div class="">inline APInt operator+(APInt &&a, const APInt &b) {</div><div class=""> ^</div><div class="">rvalue.cpp:47:14: note: candidate function</div><div class="">inline APInt operator+(const APInt &a, APInt &&b) {</div><div class=""> ^</div><div class="">rvalue.cpp:53:14: note: candidate function</div><div class="">inline APInt operator+(const APInt &a, const APInt &b) {</div><div class=""><br class=""></div></blockquote>Note, removing the && from all the variants doesn’t improve the situation.<br class=""></div></blockquote><div class=""><br class=""></div><div class="">Attached an example that I think works - but I haven't tested. There may be some accidental infinite recursion in there - the version of the patch you have didn't seem to pass all the tests anyway.<br class=""><br class="">(also noticed you ended up with both member and non-member version of unary operator-, my patch drops the member one (you could probably move operator~ out as a non-member too, but that's pretty orthogonal))</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class="">inline APInt operator-(APInt RHS, const APInt &LHS) {<br class=""> <span class="m_-1547713625398307004Apple-converted-space"> </span>RHS += LHS;<br class=""> <span class="m_-1547713625398307004Apple-converted-space"> </span>return RHS; // shouldn't need std::move here because you're returning a local<br class="">}</div></div></blockquote></span>I wondered about this too. I turned on -Wpessimizing-move to see if what I was doing was wrong but it didn’t fire. Interestingly, with this method:</div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">inline APInt operator+(APInt &&a, const APInt &b) {</div><div class=""> printf("APInt::+(&&, &)\n");</div><div class=""> a += b;</div><div class=""> return a;</div></blockquote></div></blockquote><div class=""><br class=""></div><div class="">This one shouldn't produce a move (& you should add std::move explicitly) because 'a' is not a local here, it's a reference. When it's passed by value there's no need for the std::move:<br class=""><br class=""><div class=""><font face="monospace, monospace" class="">blaikie@blaikie-linux:/tmp/dbginfo$ cat -n test.cpp</font></div><div class=""><font face="monospace, monospace" class=""> 1 struct foo {</font></div><div class=""><font face="monospace, monospace" class=""> 2 foo(foo&&) = default;</font></div><div class=""><font face="monospace, monospace" class=""> 3 };</font></div><div class=""><font face="monospace, monospace" class=""> 4 </font></div><div class=""><font face="monospace, monospace" class=""> 5 foo f(foo g) {</font></div><div class=""><font face="monospace, monospace" class=""> 6 return g;</font></div><div class=""><font face="monospace, monospace" class=""> 7 }</font></div><div class=""><font face="monospace, monospace" class=""> 8 foo f2(foo &&g) {</font></div><div class=""><font face="monospace, monospace" class=""> 9 return g;</font></div><div class=""><font face="monospace, monospace" class=""> 10 }</font></div><div class=""><font face="monospace, monospace" class="">blaikie@blaikie-linux:/tmp/dbginfo$ clang++-tot -std=c++11 test.cpp -fsyntax-only</font></div><div class=""><font face="monospace, monospace" class="">test.cpp:9:10: error: call to implicitly-deleted copy constructor of 'foo'</font></div><div class=""><font face="monospace, monospace" class=""> return g;</font></div><div class=""><font face="monospace, monospace" class=""> ^</font></div><div class=""><font face="monospace, monospace" class="">test.cpp:2:3: note: copy constructor is implicitly deleted because 'foo' has a user-declared move constructor</font></div><div class=""><font face="monospace, monospace" class=""> foo(foo&&) = default;</font></div><div class=""><font face="monospace, monospace" class=""> ^</font></div><div class=""><font face="monospace, monospace" class="">1 error generated.</font></div></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">}</div><div class=""><br class=""></div></blockquote>and with/without the std::move on the return. The above version will call APInt::APInt(&) but the std::move version will call APInt::APInt(&&). I used printfs to verify this. So looks like there is a difference here, even though I totally agree with you that we’re returning a local so it shouldn’t need the std::move. I’m not sure if this is a bug, or just subtlety in rvalue semantics. Would love to know the answer though.<div class=""><br class=""></div><div class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class="">Then you shouldn't need the op-(const APInt&,const APInt&) version, for example.<br class=""></div></div></div></blockquote></span>Not sure if its a result of the other &&’s ending up being required, but i’ve tested without a (const APInt&,const APInt&) version and I get ambiguous overload errors. Seems like i’m going to need it.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class="">Tests?</div></div></div></blockquote>I was wondering about this. I can certainly test all the variants to make sure I get the correct numerical results from APInt and I’ll add what tests are needed for that. I wouldn’t be able to test whether we get a certain number of malloc’s, unless its ok to implement my own malloc/free the APInt unit test?</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah, I'd certainly at least test that we get all the right answers (potentially using a data expanded test to exercise all the operations with the same values for different combinations of lvalues, rvalues, and uints).<br class=""><br class="">As for testing the avoidance of allocation... hrm... I mean it's essentially a non-observable performance thing, and our tests don't really test performance, so perhaps that's fine. In theory you could test that moving happened by caching the result of "getRawData" and check that the pointer value is the same? Not sure if that's a good test.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><div class="">Thanks for all the comments so far. Will try get an updated patch tomorrow.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Pete</div><div class=""><br class=""></div><div class=""></div></div></div><br class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jun 3, 2016 at 10:42 AM, Pete Cooper<span class="m_-1547713625398307004Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:peter_cooper@apple.com" target="_blank" class="">peter_cooper@apple.com</a>></span><span class="m_-1547713625398307004Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">Hi David, Sanjoy<div class=""><br class=""></div><div class="">Here’s an updated patch which provides all of the combinations of operator[+-] I can think to add.</div><div class=""><br class=""></div><div class="">All of the new ones are outside the class definition so that we can reduce duplication and have them call each other.</div><div class=""><br class=""></div><div class="">The one thing I noticed while doing this work was that the already existing operator+= and -= methods really did exactly what I wanted. So i’ve implemented + and - in terms of += and -=.</div><div class=""><br class=""></div><div class="">Is that ok, or is it frowned upon? I can imagine some people would prefer that += calls + and not the other way round. But it is very convenient as you can see with this patch.</div><div class=""><br class=""></div><div class="">Comments very welcome.</div><div class=""><br class=""></div><div class="">BTW, this reduces total allocations by about 400k from 19.1M to 18.7M.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Pete</div><div class=""><br class=""></div><div class=""></div></div><br class=""><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 3:24 PM, Pete Cooper via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank" class="">llvm-commits@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><blockquote type="cite" class=""><div class=""><br class="">On Jun 2, 2016, at 2:28 PM, Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank" class="">sanjoy@playingwithpointers.com</a>> wrote:</div><br class=""><div class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">On Wed, Jun 1, 2016 at 9:43 AM, Pete Cooper <</span><a href="mailto:peter_cooper@apple.com" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">peter_cooper@apple.com</a><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">> wrote:</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">Another interesting data point is the compile time. On my test case, SCEV::getRange is 8.9% of compile time which is a lot. But of that, 6.3% is just in ConstantRange::multiply. This method is heavy APInt code, and especially malloc traffic.<br class=""></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Yeah, that is definitely too high! Just to check: I assume you mean</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">8.9% of opt -O2 or something similar?</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""></div></blockquote>Yep, thats right. ‘opt -O2 verify-uselistorder.bc -o opt.bc’. The verify-uselistorder is the pre optimized, but post linked, bitcode when LTOing that tool.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">BTW, I just looked at the latest numbers and the commits i’ve made so far save 3% of compile time on this use case. So the 8.9% is more like 5.9% now. And still a little more to come.<br class=""><blockquote type="cite" class=""><div class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">Many of the speedup’s i’ve been finding involve doing less work (r271020 which avoids the latter half of ConstantRange::multiply and saves 3M allocations), and fixing cases of unnecessary APInt allocations (r270959). This patch is along the same lines as the latter where we have malloc traffic we can avoid.<br class=""></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Making too many fixes on the APInt algorithms to avoid allocations</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">seems like we're solving the issue at the wrong layer. I think fixing</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">infrastructural issues so that we _can_ be a little sloppy (within</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">reason) in extending integers without thinking too much about malloc</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">traffic is the right path.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""></div></blockquote>I completely agree. There are certainly limits to how far to push this. For example, this code in ConstantRange::multiply:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><blockquote style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class=""> auto L = {this_min * Other_min, this_min * Other_max,</div><div class=""> this_max * Other_min, this_max * Other_max};</div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Once I have the Rvalue ref version of the APInt methods (a change which I think is reasonable), the above could be changed to:</span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class=""> <span class="m_-1547713625398307004Apple-converted-space"> </span>auto L = {this_min * Other_min, std::move(this_min) * Other_max,</div><div class=""> this_max * std::move(Other_min), std::move(this_max) * Other_max};</div></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">This would avoid 3 allocations out of 4 because we will then use the Rvalue APInt methods. However, I think this might</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">be a little too much hacking. So yeah, I totally agree with you, and hopefully we can solve cases like this one in a more</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">reasonable way than gratuitous use of std::move() or other APInt hackery :)<br class=""><div class=""><blockquote type="cite" class=""><div class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">But you're doing the work, so you get to decide the path forward. :)</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""></div></blockquote>Sounds good to me :)<br class=""><blockquote type="cite" class=""><div class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">ConstantRange stats (bit width and count of hits in ConstantRange::ConstantRange)<br class=""></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">This is great! Is this a bootstrap of clang or something?</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""></div></blockquote>Actually same use case as before. ‘opt -O2 verify-uselistorder’. Its a nice small bit code which takes about 20s to optimize.<br class=""><blockquote type="cite" class=""><div class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Btw, there are couple of bitwidths here that I find interesting, e.g.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">I'd not have expected this many i70 ConstantRange allocations.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""></div></blockquote>Yeah, some of these are a bit surprising. 2^n and (2^n)+1 both seem likely due to the IR itself and SCEV, but anything else is a little odd. I may take a look at the 258 bit case just because there are so many of them.</div><div class=""><br class=""></div><div class="">Pete<br class=""><blockquote type="cite" class=""><div class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">-- Sanjoy</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">1: 30850028<br class="">2: 7238<br class="">3: 5733<br class="">4: 92<br class="">5: 817<br class="">6: 294<br class="">7: 192<br class="">8: 363498<br class="">9: 896<br class="">11: 330<br class="">12: 378<br class="">13: 385<br class="">14: 125<br class="">16: 30256<br class="">18: 272<br class="">20: 98<br class="">24: 10<br class="">25: 62<br class="">26: 13<br class="">27: 181<br class="">28: 8<br class="">31: 98<br class="">32: 2003134<br class="">33: 132<br class="">34: 128<br class="">36: 76<br class="">38: 2130<br class="">41: 3<br class="">57: 262<br class="">58: 244<br class="">59: 342<br class="">60: 2418<br class="">61: 1211<br class="">62: 190<br class="">63: 226<br class="">64: 5118228<br class="">65: 128400<br class="">66: 4236<br class="">67: 14826<br class="">68: 15408<br class="">69: 13417<br class="">70: 7959<br class="">71: 347<br class="">96: 88<br class="">128: 364826<br class="">129: 379580<br class="">130: 19092<br class="">256: 4734<br class="">257: 19132<br class="">258: 71826<br class="">514: 4650<br class=""></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">--<span class=""> </span></span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Sanjoy Das</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="http://playingwithpointers.com/" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">http://playingwithpointers.com</a></div></blockquote></div><br class=""></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">llvm-commits mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="mailto:llvm-commits@lists.llvm.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">llvm-commits@lists.llvm.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a></div></blockquote></div><br class=""></div></div><br class=""></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div><br class=""></blockquote></div><br class=""></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><span id="m_-1547713625398307004cid:FE50F656-2B4E-4B15-9EAE-7E9660289342@apple.com" class=""><apint.diff></span></div></blockquote></div><br class=""></div></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>