LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 19059 - Generating 64-bit movd after cmpneqsd when targeting 32-bit mode
Summary: Generating 64-bit movd after cmpneqsd when targeting 32-bit mode
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Backend: X86 (show other bugs)
Version: trunk
Hardware: PC Windows NT
: P normal
Assignee: Hans Wennborg
URL:
Keywords:
Depends on:
Blocks: 18887
  Show dependency tree
 
Reported: 2014-03-05 19:26 PST by Hans Wennborg
Modified: 2014-03-11 10:51 PDT (History)
3 users (show)

See Also:
Fixed By Commit(s):


Attachments
Preprocessed input (1.12 KB, application/octet-stream)
2014-03-05 19:26 PST, Hans Wennborg
Details
bitcode repro (5.35 KB, application/octet-stream)
2014-03-05 19:28 PST, Hans Wennborg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans Wennborg 2014-03-05 19:26:54 PST
Created attachment 12195 [details]
Preprocessed input

To reproduce:

  clang -cc1 -triple i386-pc-win32 -mstackrealign -target-cpu pentium4 -fms-extensions -S -o - b.ii

We're miscompiling this statement:

  updateAnimations(SMILTime(m_presetStartTime), m_presetStartTime ? true : false);

In Clang's asm printout, we have this:

        movsd   32(%edx), %xmm0
        xorps   %xmm1, %xmm1
        cmpneqsd        %xmm0, %xmm1
        movd    %xmm1, %rsi

Note that the last instruction tries to move xmm1 to a 64-bit register, but we're targeting i386.

Disassembling the object file shows different instructions:

  000000AE: F2 0F 10 42 20     movsd       xmm0,mmword ptr [edx+20h]
  000000B3: 0F 57 C9           xorps       xmm1,xmm1
  000000B6: F2 0F C2 C8 04     cmpneqsd    xmm1,xmm0
  000000BB: 66 0F 7E CE        movd        esi,xmm1

Turns out our 64-bit move to rsi becomes a 32-bit move into esi? But esi is used as base pointer in this function; we have now clobbered it and will crash a few lines down.

The 64-bit move looks like this (this is from "Before Expand ISel Pseudo-instructions"):

	%vreg32<def> = FsFLD0SD; FR64:%vreg32
	%vreg33<def,tied1> = CMPSDrr %vreg32<tied0>, %vreg31<kill>, 4; FR64:%vreg33,%vreg32,%vreg31
	%vreg34<def> = MOVSDto64rr %vreg33<kill>; GR64:%vreg34 FR64:%vreg33

after register allocation, we think we're moving into rsi:

	%XMM1<def> = FsFLD0SD
	%XMM1<def,tied1> = CMPSDrr %XMM1<tied0>, %XMM0<kill>, 4
	%RSI<def> = MOVSDto64rr %XMM1<kill>

There's something strange going on here :)


(This is reduced from WebCore::SMILTimeContainer::begin.)
Comment 1 Hans Wennborg 2014-03-05 19:28:52 PST
Created attachment 12196 [details]
bitcode repro

Attaching .ll file that shows the problem when compiled with

  llc -O0 -mcpu=pentium4 -force-align-stack a.ll -o -
Comment 2 Craig Topper 2014-03-06 02:26:34 PST
Far as I can tell the bug was introduced in r197384. Going to do some more digging to see what happened before that.
Comment 3 Hans Wennborg 2014-03-11 10:51:25 PDT
Fixed in r203581.