search for: movimm

Displaying 15 results from an estimated 15 matches for "movimm".

2016 Aug 22
3
Instruction itineraries and fence/barrier instructions
...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...
2016 Aug 22
2
Instruction itineraries and fence/barrier instructions
...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...
2016 Jan 13
2
Expanding a PseudoOp and accessing the DAG
...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...
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
...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...
2016 Jan 13
2
Expanding a PseudoOp and accessing the DAG
...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...
2018 Feb 09
2
[X86] MoveImm flag for instructions
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...
2016 Jan 07
2
TableGen error message: top-level forms in instruction pattern should have void types
...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...
2018 Feb 09
2
[X86] MoveImm flag for instructions
...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...
2018 Feb 09
0
[X86] MoveImm flag for instructions
...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 i...
2018 Feb 09
0
[X86] MoveImm flag for instructions
...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...
2016 Jan 07
2
TableGen error message: top-level forms in instruction pattern should have void types
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), >>
2016 Nov 03
2
rotl: undocumented LLVM instruction?
...# 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...
2016 Nov 03
3
rotl: undocumented LLVM instruction?
...;> 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...
2016 Nov 03
2
rotl: undocumented LLVM instruction?
...; 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...
2016 Nov 02
3
rotl: undocumented LLVM instruction?
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