search for: movsdrms

I have an llvm ir, which generates the following machine code using llc (llvm 3.0 on win32) after # *** IR Dump After X86 DAG->DAG Instruction Selection ***: The first three lines and the last two lines alone together are used to compute "sin" for some double number. - line 1: move the stack pointer down 8 - line 2: copy the updated stack pointer to a base register - line 3: copy a

...LD(8,8) [r30158 + 0]LD(8,8) [r45154 + 0] ; srcLine 10 %reg1064<def> = MOVSD2PDrm %reg1026, 8, %reg1059, 4294967288, Mem:LD(8,8) [r30158 + 0]LD(8,8) [r45154 + 0] ; srcLine 10 %reg1065<def> = SHUFPDrri %reg1063, %reg1064, 0 ; srcLine 10 Where the <bleep> are these extra dead MOVSDrms coming from? Note that the extra MOVSDrms at least seem to use the correct addresses. -Dave

Hi Peng, Can you please open a bugzilla and attache the LL file ? Can you please reproduce it on ToT ? Thanks, Nadav On Feb 7, 2013, at 9:08 PM, Peng Cheng <gm4cheng at gmail.com> wrote: > I have an llvm ir, which generates the following machine code using llc (llvm 3.0 on win32) after # *** IR Dump After X86 DAG->DAG Instruction Selection ***: > > The first three lines

...r45154 + 0] ; srcLine 10 > %reg1064<def> = MOVSD2PDrm %reg1026, 8, %reg1059, 4294967288, > Mem:LD(8,8) > [r30158 + 0]LD(8,8) [r45154 + 0] ; srcLine 10 > %reg1065<def> = SHUFPDrri %reg1063, %reg1064, 0 ; srcLine 10 > > Where the <bleep> are these extra dead MOVSDrms coming from? Note > that the > extra MOVSDrms at least seem to use the correct addresses. Looking at your dump() output above, it looks like the pre-selection loads have multiple uses, so even though you've managed to match a larger pattern that incorporates them, they still need to e...

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

I sent a long message yesterday describing a problem I thought had to do with the JIT stubs. After further investigating, the problem seems to be in the code generation. The following basic block seems to have an error in it's code generation: __exp.exit: ; preds = %codeRepl258, %__exp_bb_bb.exit phi double [ 1.000000e+00, %codeRepl258 ], [ %.reload.reload.i,

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: