<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hans,<div><br><div><div>On Mar 13, 2014, at 12:27 PM, Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Thu, Mar 13, 2014 at 11:27 AM, Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>> wrote:<br><blockquote type="cite">Hi Owen,<br><br>On Wed, Mar 12, 2014 at 11:02 PM, Owen Anderson <<a href="mailto:resistor@mac.com">resistor@mac.com</a>> wrote:<br><blockquote type="cite">Author: resistor<br>Date: Thu Mar 13 01:02:25 2014<br>New Revision: 203757<br><br>URL: <a href="http://llvm.org/viewvc/llvm-project?rev=203757&view=rev">http://llvm.org/viewvc/llvm-project?rev=203757&view=rev</a><br>Log:<br>Phase 1 of refactoring the MachineRegisterInfo iterators to make them suitable<br>for use with C++11 range-based for-loops.<br><br>The gist of phase 1 is to remove the skipInstruction() and skipBundle()<br>methods from these iterators, instead splitting each iterator into a version<br>that walks operands, a version that walks instructions, and a version that<br>walks bundles. This has the result of making some "clever" loops in lib/CodeGen<br>more verbose, but also makes their iterator invalidation characteristics much<br>more obvious to the casual reader. (Making them concise again in the future is a<br>good motivating case for a pre-incrementing range adapter!)<br><br>Phase 2 of this undertaking with consist of removing the getOperand() method,<br>and changing operator*() of the operand-walker to return a MachineOperand&. At<br>that point, it should be possible to add range views for them that work as one<br>might expect.<br></blockquote><br>It seems this causes us to miscompile yasm on Windows (which we build<br>and use as part of Chromium).<br><br>I have no idea what's going on yet, but I'm working on a repro.<br></blockquote><br>When compiling the attached .ii file like this:<br><br>clang "-cc1" "-triple" "i386-pc-win32" "-emit-obj"<br>"-mrelocation-model" "static" "-mdisable-fp-elim" "-fmath-errno"<br>"-masm-verbose" "-mconstructor-aliases" "-target-cpu" "pentium4"<br>"-gline-tables-only" "-O2" "-mstackrealign" "-fno-rtti"<br>"-fms-extensions" "-fms-compatibility" "-fmsc-version=1800"<br>"-vectorize-loops" "-vectorize-slp" "-S" "-o"<br>"d:\src\tmp\yasm.bitvect.asm" "-x" "c"<br>"d:\src\tmp\yasm.bitvect.reduced.ii" -w<br><br>I get different output before and after your commit. Specifically in<br>the _BitVector_from_Dec_static function, looking at the diff of asm<br>before and after, it seems like the spill of %esi is missing, which<br>could be causing the problem I see.<br><br>Do you have any idea of what could be happening here?<br></div></blockquote><br></div></div><div>I’m getting errors from my clang when I try to compile your preprocessed source. Is there any chance you can capture a bitcode file that exhibits the problem in llc?</div><div><br></div><div>—Owen</div></body></html>