search for: movsdrm

...%vreg36; mem:ST8[Stack] GR32:%vreg187 FR64:%vreg36 ; line 3 %vreg188<def> = MOV32rm %vreg112, 1, %noreg, 252, %noreg; mem:LD4[%108] GR32:%vreg188,%vreg112 %vreg189<def> = MOV32rm %vreg112, 1, %noreg, 256, %noreg; mem:LD4[%111] GR32:%vreg189,%vreg112 %vreg190<def> = MOVSDrm <fi#0>, 1, %noreg, 120, %noreg; mem:LD8[%85] FR64:%vreg190 %vreg191<def> = MOVSDrm <fi#0>, 1, %noreg, 96, %noreg; mem:LD8[%87] FR64:%vreg191 %vreg192<def> = MOVSDrm <fi#0>, 1, %noreg, 88, %noreg; mem:LD8[%92] FR64:%vreg192 %vreg193<def> = MOVSDrm <fi#0>,...

...worse than this. I wanted to check to make sure something else wasn't causing the problem but it appears to come from isel. The full output for the DAG looks like this: %reg1059<def> = MOVSX64rm32 %reg1033, 1, %reg0, 4, Mem:LD(4,4) [tmp163 + 0] ; srcLine 10 %reg1060<def> = MOVSDrm %reg1026, 8, %reg1059, 4294967288, Mem:LD(8,8) [r45154 + 0] ; srcLine 10 %reg1061<def> = MOVSX64rm32 %reg1033, 1, %reg0, 0, Mem:LD(4,4) [iv.161162 + 0] ; srcLine 10 %reg1062<def> = MOVSDrm %reg1026, 8, %reg1061, 4294967288, Mem:LD(8,8) [r30158 + 0] ; srcLine 10 %reg1063<def&...

...[Stack] GR32:%vreg187 FR64:%vreg36 ; line 3 > %vreg188<def> = MOV32rm %vreg112, 1, %noreg, 252, %noreg; mem:LD4[%108] GR32:%vreg188,%vreg112 > %vreg189<def> = MOV32rm %vreg112, 1, %noreg, 256, %noreg; mem:LD4[%111] GR32:%vreg189,%vreg112 > %vreg190<def> = MOVSDrm <fi#0>, 1, %noreg, 120, %noreg; mem:LD8[%85] FR64:%vreg190 > %vreg191<def> = MOVSDrm <fi#0>, 1, %noreg, 96, %noreg; mem:LD8[%87] FR64:%vreg191 > %vreg192<def> = MOVSDrm <fi#0>, 1, %noreg, 88, %noreg; mem:LD8[%92] FR64:%vreg192 > %vreg193<def> = MOVSDr...

...re > something > else wasn't causing the problem but it appears to come from isel. > The full > output for the DAG looks like this: > > %reg1059<def> = MOVSX64rm32 %reg1033, 1, %reg0, 4, Mem:LD(4,4) > [tmp163 + > 0] ; srcLine 10 > %reg1060<def> = MOVSDrm %reg1026, 8, %reg1059, 4294967288, > Mem:LD(8,8) > [r45154 + 0] ; srcLine 10 > %reg1061<def> = MOVSX64rm32 %reg1033, 1, %reg0, 0, Mem:LD(4,4) [iv. > 161162 + > 0] ; srcLine 10 > %reg1062<def> = MOVSDrm %reg1026, 8, %reg1061, 4294967288, > Mem:LD(8,8) > [...

On Thursday 02 October 2008 11:37, David Greene wrote: > I'll try ot write a small example and send it in a bit. Ok, here's what I'm trying to do: let AddedComplexity = 40 in { def : Pat<(v2f64 (vector_shuffle (v2f64 (scalar_to_vector (loadf64 addr: $src1))), (v2f64 (scalar_to_vector (loadf64 addr: $src2))),

I'm debugging some X86 patterns and I want to understand the debug dumps from isel better. Here's some example output: 0x391bc40: i64,ch = load 0x3922c50, 0x391b8d0, 0x38dc530 <0x39053e0:0> <sext i32> alignment=4 srcLineNum= 10 0x3922c50: <multiple use> 0x391bc40: <multiple use> 0x3856ab0: <multiple use> 0x3914520: i64 =

I am working on a project where we are integrating an existing pre-RA scheduler into LLVM and we are trying to match our peak register pressure values with the machine instruction schedulers values while using X86. I am finding some mismatches in test cases like the one attached. The registers "AH" and "AL" are live-out but not live-in and I don't see that they are defined

On 02/27/2018 10:21 AM, Alex Wang via llvm-dev wrote: > Hello all! > > I was looking through the results of disassembling a heavily-used > short function > in the program I'm working on, and ended up wondering why LLVM was > generating > that assembly and what changes would be necessary to improve the code. > I asked > on #llvm, but it seems that the people with

..., 1073741824 MOV32mi %ESP, 1, %NOREG, 12, 1079574528 MOV32mi %ESP, 1, %NOREG, 8, 0 CALLpcrel32 <es:fmod> %ESP = ADD32ri8 %ESP, 16 FSTP64m %EBP, 1, %NOREG, -160 %EAX = MOV32rm %EBP, 1, %NOREG, -224 %EAX = ADD32ri8 %EAX, 24 %XMM0 = MOVSDrm %EBP, 1, %NOREG, -160 MOVSDmr %EBP, 1, %NOREG, -232, %XMM0 MOVSDmr %EAX, 1, %NOREG, 0, %XMM0 %EAX = CVTTSD2SIrm %ESI, 1, %NOREG, 0 %ECX = MOV32r0 TEST32rr %EAX, %EAX JNE mbb<bb.preheader.i271,0x8c55330> Successors according to CFG: 0x8c55330...

Hello all! I was looking through the results of disassembling a heavily-used short function in the program I'm working on, and ended up wondering why LLVM was generating that assembly and what changes would be necessary to improve the code. I asked on #llvm, but it seems that the people with the necessary expertise weren't around. Here is a condensed version of the code: