[llvm] r203757 - Phase 1 of refactoring the MachineRegisterInfo iterators to make them suitable

Hans Wennborg hans at chromium.org
Thu Mar 13 13:29:35 PDT 2014


On Thu, Mar 13, 2014 at 12:40 PM, Owen Anderson <resistor at mac.com> wrote:
> Hans,
>
> On Mar 13, 2014, at 12:27 PM, Hans Wennborg <hans at chromium.org> wrote:
>
> On Thu, Mar 13, 2014 at 11:27 AM, Hans Wennborg <hans at chromium.org> wrote:
>
> Hi Owen,
>
> On Wed, Mar 12, 2014 at 11:02 PM, Owen Anderson <resistor at mac.com> wrote:
>
> Author: resistor
> Date: Thu Mar 13 01:02:25 2014
> New Revision: 203757
>
> URL: http://llvm.org/viewvc/llvm-project?rev=203757&view=rev
> Log:
> Phase 1 of refactoring the MachineRegisterInfo iterators to make them
> suitable
> for use with C++11 range-based for-loops.
>
> The gist of phase 1 is to remove the skipInstruction() and skipBundle()
> methods from these iterators, instead splitting each iterator into a version
> that walks operands, a version that walks instructions, and a version that
> walks bundles.  This has the result of making some "clever" loops in
> lib/CodeGen
> more verbose, but also makes their iterator invalidation characteristics
> much
> more obvious to the casual reader. (Making them concise again in the future
> is a
> good motivating case for a pre-incrementing range adapter!)
>
> Phase 2 of this undertaking with consist of removing the getOperand()
> method,
> and changing operator*() of the operand-walker to return a MachineOperand&.
> At
> that point, it should be possible to add range views for them that work as
> one
> might expect.
>
>
> It seems this causes us to miscompile yasm on Windows (which we build
> and use as part of Chromium).
>
> I have no idea what's going on yet, but I'm working on a repro.
>
>
> When compiling the attached .ii file like this:
>
> clang "-cc1" "-triple" "i386-pc-win32" "-emit-obj"
> "-mrelocation-model" "static" "-mdisable-fp-elim" "-fmath-errno"
> "-masm-verbose" "-mconstructor-aliases" "-target-cpu" "pentium4"
> "-gline-tables-only"  "-O2"  "-mstackrealign" "-fno-rtti"
> "-fms-extensions" "-fms-compatibility" "-fmsc-version=1800"
> "-vectorize-loops" "-vectorize-slp" "-S" "-o"
> "d:\src\tmp\yasm.bitvect.asm" "-x" "c"
> "d:\src\tmp\yasm.bitvect.reduced.ii" -w
>
> I get different output before and after your commit. Specifically in
> the _BitVector_from_Dec_static function, looking at the diff of asm
> before and after, it seems like the spill of %esi is missing, which
> could be causing the problem I see.
>
> Do you have any idea of what could be happening here?
>
>
> 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?

Attaching the bitcode. This is how I run it:

D:\src\llvm\build.release>bin\llc-bad.exe -mtriple i386-pc-win32
-disable-fp-elim -mcpu=pentium4 -O2 -force-align-stack
d:\src\tmp\yasm.bitvect.bc -o d:\src\tmp\bad.asm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yasm.bitvect.bc.gz
Type: application/x-gzip
Size: 145496 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140313/9ff97ad9/attachment.bin>


More information about the llvm-commits mailing list