search for: mov64ri32

...@@ -1832,6 +1832,8 @@ (MOV64ri64i32 tjumptable :$dst)>, Requires<[SmallCode]>; def : Pat<(i64 (X86Wrapper tglobaladdr :$dst)), (MOV64ri64i32 tglobaladdr :$dst)>, Requires<[SmallCode]>; +def : Pat<(i64 (X86Wrapper tglobaltlsaddr :$dst)), + (MOV64ri32 tglobaltlsaddr :$dst)>, Requires<[SmallCode]>; def : Pat<(i64 (X86Wrapper texternalsym:$dst)), (MOV64ri64i32 texternalsym:$dst)>, Requires<[SmallCode]>; def : Pat<(i64 (X86Wrapper tblockaddress:$dst)), Unfortunately, I am 100% confident with this modificatio...

...> (MOV64ri64i32 tjumptable :$dst)>, Requires<[SmallCode]>; > def : Pat<(i64 (X86Wrapper tglobaladdr :$dst)), > (MOV64ri64i32 tglobaladdr :$dst)>, Requires<[SmallCode]>; > +def : Pat<(i64 (X86Wrapper tglobaltlsaddr :$dst)), > + (MOV64ri32 tglobaltlsaddr :$dst)>, Requires<[SmallCode]>; > def : Pat<(i64 (X86Wrapper texternalsym:$dst)), > (MOV64ri64i32 texternalsym:$dst)>, Requires<[SmallCode]>; > def : Pat<(i64 (X86Wrapper tblockaddress:$dst)), > > Unfortunately, I am 100% confident...

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/memor...

...OV64ri64i32 tjumptable :$dst)>, Requires<[SmallCode]>; >> def : Pat<(i64 (X86Wrapper tglobaladdr :$dst)), >> (MOV64ri64i32 tglobaladdr :$dst)>, Requires<[SmallCode]>; >> +def : Pat<(i64 (X86Wrapper tglobaltlsaddr :$dst)), >> + (MOV64ri32 tglobaltlsaddr :$dst)>, Requires<[SmallCode]>; >> def : Pat<(i64 (X86Wrapper texternalsym:$dst)), >> (MOV64ri64i32 texternalsym:$dst)>, Requires<[SmallCode]>; >> def : Pat<(i64 (X86Wrapper tblockaddress:$dst)), >> >> Unfortunatel...

...i, Feb 9, 2018 at 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 de...

...trying to do? ~Craig On Fri, Feb 9, 2018 at 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...

...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 >>> be...

...t; = COPY %vreg5; GR64:%vreg5 INLINEASM <es:> [sideeffect] [attdialect], $0:[reguse], %RDX %vreg6<def> = MOV64ri64i32 1; GR64:%vreg6 %RSI<def> = COPY %vreg6; GR64:%vreg6 INLINEASM <es:> [sideeffect] [attdialect], $0:[reguse], %RSI %vreg7<def> = MOV64ri32 -1; GR64:%vreg7 %RDI<def> = COPY %vreg7; GR64:%vreg7 INLINEASM <es:> [sideeffect] [attdialect], $0:[reguse], %RDI INLINEASM <es:> [sideeffect] [attdialect], $0:[regdef], %RDI<imp-def> %vreg8<def> = COPY %RDI; GR64:%vreg8 %vreg2<def> = MOV...

...:$dst)>, Requires<[SmallCode]>; >>> def : Pat<(i64 (X86Wrapper tglobaladdr :$dst)), >>> (MOV64ri64i32 tglobaladdr :$dst)>, Requires<[SmallCode]>; >>> +def : Pat<(i64 (X86Wrapper tglobaltlsaddr :$dst)), >>> + (MOV64ri32 tglobaltlsaddr :$dst)>, Requires<[SmallCode]>; >>> def : Pat<(i64 (X86Wrapper texternalsym:$dst)), >>> (MOV64ri64i32 texternalsym:$dst)>, Requires<[SmallCode]>; >>> def : Pat<(i64 (X86Wrapper tblockaddress:$dst)), >>&gt...

...s) { > + const MachineOperand &MO1 = MI.getOperand(CurOp++); > + unsigned Size = X86InstrInfo::sizeOfImm(Desc); > + if (MO1.isImmediate()) > + FinalSize += sizeConstant(Size); > + else { > + bool dword = false; > + if (Opcode == X86::MOV64ri32) > + dword = true; > + if (MO1.isGlobalAddress()) { > + FinalSize += sizeGlobalAddress(dword); > + } else if (MO1.isExternalSymbol()) > + FinalSize += sizeExternalSymbolAddress(dword); > + else if (MO1.isConstantPoolIndex()) > +...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And