search for: movimm

...instruction itineraries the code generated was: xstg_intrinsic: # @xstg_intrinsic # BB#0: # %entry subI r509, r509, 16, 64 store r510, r509, 0, 64 bitop1 r510, r509, 0, OR, 64 store r0, r510, 12, 32 movimm r1, %hi(write_me), 64 movimmshf32 r1, r1, %lo(write_me) store r0, r1, 0, 32 fence 2 movimm r0, %hi(read_me), 64 movimmshf32 r0, r0, %lo(read_me) load r1, r0, 0, 32 bitop1 r509, r510, 0, OR, 64 load r510, r509, 0, 64...

...sic: # @xstg_intrinsic > > # BB#0: # %entry > > subI r509, r509, 16, 64 > > store r510, r509, 0, 64 > > bitop1 r510, r509, 0, OR, 64 > > store r0, r510, 12, 32 > > movimm r1, %hi(write_me), 64 > > movimmshf32 r1, r1, %lo(write_me) > > store r0, r1, 0, 32 > > fence 2 > > movimm r0, %hi(read_me), 64 > > movimmshf32 r0, r0, %lo(read_me) > > load r1, r0, 0, 32 > > bit...

...allocation. In > other words, quite late in the entire optimization sequence. Most of the > actual optimization work is pretty much done at this point. > > > [as an aside, we've got patterns like: >> >> def : Pat<(XSTGMVINI tglobaladdr:$off), >> (MOVIMMZ_I64 tglobaladdr:$off)>; >> >> ] >> > > I'm not sure if the input will match if you have tglobaladdr in it. The > 't' means "target", and in this context it means that the argument has > already been handled by the target and is in a form that...

...ers >> to be pointers to various address spaces (and our processor is rather >> complicated so there are several address spaces). >> >> Right now, given a global variable called 'answer' in C we end up with >> the following in the .s file: >> >> movimm r1, %rel(answer) # r1 <- offset to 'answer' symbol >> load r1, r1, 0 # r1<-mem[r1+0] >> >> This isn't correct because it should be relative to the GRP register if >> the PIE mode is chosen, what I'd like to get is either: &g...

...I'm a bit worried that expansion happens too late (after things should already be MI's, it seems). So things like patterns that try to match on that XSTGMVINI would have already been matched. [as an aside, we've got patterns like: def : Pat<(XSTGMVINI tglobaladdr:$off), (MOVIMMZ_I64 tglobaladdr:$off)>; ] So, first off, if I wanted to expand that DAG for the RelAddr Node, and I want something like (the first BuildMI below is pseudo code as I'm not sure how to accomplish it): case XSTG::RelAddr: BuildMI(MBB, MI, DL, MI->getOperand(1).DAG...) ??? BuildM...

Hi, I had (naively?) expected that the instruction to move immediate to register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, MOV64ri32) would be marked with the flag MCID::MovImm via the X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). I do not see that to be the case. Can someone please tell me if my expectation is flawed? Is there a better/different way to determine to test for move immediate to register/memory instruction on X86 other that the existing...

...tly this produces the following assembly code: .Ltmp0: .cfi_def_cfa_offset 48 store r510, r509, 0, 64 .Ltmp1: .cfi_offset 510, -48 bitop1 r510, r509, 0, OR, 64 .Ltmp2: .cfi_def_cfa_register 510 store r0, r510, 44, 32 store r1, r510, 32, 64 movimm r0, %hi(xint), 64 movimmshf32 r0, r0, %lo(xint) movimm r1, %rel(answer), 64 #<--- relevant lines load r1, r1, 0, 32 #<--- ... (%rel is a macro that returns the delta from the global section to the 'answer' symbol) Instead of t...

...lli via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I had (naively?) expected that the instruction to move immediate to >> register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, >> MOV64ri32) would be marked with the flag MCID::MovImm via the >> X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). >> >> I do not see that to be the case. >> >> Can someone please tell me if my expectation is flawed? Is there a >> better/different way to determine to test for move immediate to >&g...

...11:45 AM, S. Bharadwaj Yadavalli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I had (naively?) expected that the instruction to move immediate to > register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, > MOV64ri32) would be marked with the flag MCID::MovImm via the > X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). > > I do not see that to be the case. > > Can someone please tell me if my expectation is flawed? Is there a > better/different way to determine to test for move immediate to > register/memory instructi...

...t; llvm-dev at lists.llvm.org> wrote: >> >>> Hi, >>> >>> I had (naively?) expected that the instruction to move immediate to >>> register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, >>> MOV64ri32) would be marked with the flag MCID::MovImm via the >>> X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). >>> >>> I do not see that to be the case. >>> >>> Can someone please tell me if my expectation is flawed? Is there a >>> better/different way to determine to test for...

On Thu, Jan 7, 2016 at 12:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 1/7/2016 1:55 PM, Phil Tomson via llvm-dev wrote: > >> >> let Uses= [GRP] in { >> def RelAddr : XSTGPseudo< (outs), >> (ins GPRC:$spoff, GPRC:$dst), >>

...# BB#0: # %entry addI r1, r1, -1, 64 bclr r1, r0, r1, 64 jabs r511 Whereas with 3.9 the generated code is: bclr64: # @bclr64 # BB#0: # %entry addI r1, r1, -1, 64 movimm r2, -2, 64 rol r1, r2, r1, 64 bitop1 r1, r0, r1, AND, 64 jabs r511 ... it seems to be negatively impacting some of our larger benchmarks as well that used to contains several bclr (bit clear) commands but now contain much less. Phil On Wed, Nov 2, 2016...

...;> bclr r1, r0, r1, 64 >> jabs r511 >> >> Whereas with 3.9 the generated code is: >> >> bclr64: # @bclr64 >> # BB#0: # %entry >> addI r1, r1, -1, 64 >> movimm r2, -2, 64 >> rol r1, r2, r1, 64 >> bitop1 r1, r0, r1, AND, 64 >> jabs r511 >> >> >> ... it seems to be negatively impacting some of our larger benchmarks as >> well that used to contains several bclr (bit clear) comm...

...; jabs r511 > > Whereas with 3.9 the generated code is: > > bclr64: # @bclr64 > # BB#0: # %entry > addI r1, r1, -1, 64 > movimm r2, -2, 64 > rol r1, r2, r1, 64 > bitop1 r1, r0, r1, AND, 64 > jabs r511 > > > ... it seems to be negatively impacting some of our larger > benchmarks as well that used to contai...

We've recently moved our project from LLVM 3.6 to LLVM 3.9. I noticed one of our code generation tests is breaking in 3.9. The test is: ; RUN: llc < %s -march=xstg | FileCheck %s define i64 @bclr64(i64 %a, i64 %b) nounwind readnone { entry: ; CHECK: bclr r1, r0, r1, 64 %sub = sub i64 %b, 1 %shl = shl i64 1, %sub %xor = xor i64 %shl, -1 %and = and i64 %a, %xor ret i64