search for: sub_32bit

...election DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer. > > The COPY instruction handles subreg operations with less redundancy: > > %reg1045<def> = EXTRACT_SUBREG %reg1044<kill>, 4 > %reg1045<def> = COPY %reg1044:sub_32bit<kill> > > %reg1045<def> = INSERT_SUBREG %reg1045, %reg1044<kill>, 4 > %reg1045:sub_32bit<def> = COPY %reg1044<kill> > > %reg1050:ssub_0<def> = EXTRACT_SUBREG %reg1060:dsub_1<kill>, ssub_0 > %reg1050:ssub_0<def> = COPY %reg1060:...

...instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer. The COPY instruction handles subreg operations with less redundancy: %reg1045<def> = EXTRACT_SUBREG %reg1044<kill>, 4 %reg1045<def> = COPY %reg1044:sub_32bit<kill> %reg1045<def> = INSERT_SUBREG %reg1045, %reg1044<kill>, 4 %reg1045:sub_32bit<def> = COPY %reg1044<kill> %reg1050:ssub_0<def> = EXTRACT_SUBREG %reg1060:dsub_1<kill>, ssub_0 %reg1050:ssub_0<def> = COPY %reg1060:ssub_2<kill> It will al...

...egister copies equally. > If the 128-bit register is not ever used as a 128-bit register, > shouldn't the coalescer pick the 64- or 32-bit register? That optimization is not currently implemented for sub-registers. For example, if you create a GR64 virtual register and only ever use the sub_32bit sub-register, it would be possible to replace the virtual register with a GR32 register. It's not impossible to do, but it doesn't come up a lot. When not using sub-registers, the optimization does exist. For example, if you have a VR128 virtual register, but all the instructions using it...

i have loop index I. I want to increment it by 1. How to do this in registerinfo.td. I m trying following but getting error. let SubRegIndices = [sub_32bit, sub_32bit_hi], CoveredBySubRegs = 1 in { foreach I = 0-255 in { m=add(I,1); def R_#J#_REG64b_#I : R_P<"R_"#J#"_R64b_"#I, !shl(I,2), [!cast<R_P>("R_"#J#"_REG32b_"#I), !cast<R_PIM>("R_"#J#"_REG32b_"#m)]>; } } plea...

...t;> If the 128-bit register is not ever used as a 128-bit register, >> shouldn't the coalescer pick the 64- or 32-bit register? > > That optimization is not currently implemented for sub-registers. For > example, if you create a GR64 virtual register and only ever use the > sub_32bit sub-register, it would be possible to replace the virtual > register with a GR32 register. It's not impossible to do, but it > doesn't come up a lot. It does come up a lot in vector code. Extraction of scalar values from vectors is pretty common, especially given the limitations of...

...be /// used to determine if sub-registers overlap - they can't be used to /// determine if a set of sub-registers completely cover another /// sub-register. /// /// The X86 general purpose registers have two lanes corresponding to the /// sub_8bit and sub_8bit_hi sub-registers. Both sub_32bit and sub_16bit have /// lane masks '3', but the sub_16bit sub-register doesn't fully cover the /// sub_32bit sub-register. /// /// On the other hand, the ARM NEON lanes fully cover their registers: The /// dsub_0 sub-register is completely covered by the ssub_0 and ssub_1 lanes...

On Sep 1, 2010, at 11:14 AM, Dale Johannesen wrote: > > On Sep 1, 2010, at 6:25 AMPDT, Argyrios Kyrtzidis wrote: > >> The attached .ll files seem equivalent, but the resulting asm from >> 'opt-fail.ll' causes a crash to webkit. >> I suspect the usage of registers is wrong, can someone take a look ? > > Yes, the code here is wrong: > >> movl

The function TII::canCombineSubRegIndices has been gone for a while now, and I was wondering if there is a target-independent way of determining if a certain set of physical registers "adds up" to a larger register. For example, on X86, AL and AH together form AX. On Hexagon, R0 and R1 are D0. The context here is an attempt to coalesce multiple loads/stores into fewer loads/stores

...struction, but there isn't really any way around that. There are some existing patterns involving MOV32rm, if you want inspiration; for example, the following pattern is from X86InstrCompiler.td: def : Pat<(extloadi64i32 addr:$src), (SUBREG_TO_REG (i64 0), (MOV32rm addr:$src), sub_32bit)>; -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/at...

Hi all, I am experiencing a problem with the representation of addresses in the x86_64 TableGen backend and was hoping someone can tell me if it is fixable. Any comments or hints in to send me in the right direction would be greatly appreciated. I am using LLVM version 3.8, commit 251286. I have an IR pass that stores metadata in the upper 32 bits of 64-bit pointers in order to implement

Jakob Stoklund Olesen <jolesen at apple.com> writes: >> What happens if the result of the above pattern using COPY_TO_REGCLASS >> is spilled? Will we get a 64-bit store or a 128-bit store? > > This behavior isn't affected by the change. FR64 registers are spilled > with 64-bit stores, and VR128 registers are spilled with 128-bit > stores. > > When the

...of the constant. Here's a snippet of MIR output that illustrates the problem: %19:gr64 = ADD64ri8 %18, 8, implicit-def dead %eflags; GR64:%19,%18 dbg:destroy-after-foreach.swift:2:7 %20:gr32 = MOV32ri64 1; GR32:%20 dbg:destroy-after-foreach.swift:1:44 %21:gr64 = SUBREG_TO_REG 0, killed %20, sub_32bit; GR64:%21 GR32:%20 dbg:destroy-after-foreach.swift:1:44 %rdi = COPY %21; GR64:%21 dbg:destroy-after-foreach.swift:2:7 The out-of-order stepping behavior is confusing and unexpected to users. ISTM that the simplest way to fix this bug is to not attach debug locations to constant SDNodes. This matc...

On Jul 26, 2012, at 9:43 AM, dag at cray.com wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> As far as I can tell, all sub-register operations involving sub_ss and >> sub_sd can simply be replaced with COPY_TO_REGCLASS: >> >> def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), >> (VMOVSDrr VR128:$src1,

...ub_32768bit_hi], CoveredBySubRegs >>>>> = 1 in >>>>> >>>>> but i am getting following error.. >>>>> >>>>> error:Ran out of lanemask bits to represent subregister >>>>> sub_32768bit_hi_then_sub_16384bit_hi_then_sub_32bit >>>>> >>>>> now how to increase lanemask bits? what changes are required >>>>> in IntrinsicEmitter.cpp file?? >>>>> >>>>> Please reply. >>>>> >>>>> >>>>> >>>> >>...

I have made changes in 3 files: LaneBitmask.h, codegenregisters.cpp and miparser.cpp. files are attached here. Now i am getting following errors. which means registerinfo.inc file is not generated successfully. /PIM/lib/Target/X86/MCTargetDesc/X86BaseInfo.h:733:24: error: no member named 'XMM8' in namespace 'llvm::X86' if ((RegNo >= X86::XMM8 && RegNo <=

Hi Susan, The problem now is the usedPregSet. Take the instruction: %vreg13:sub_32bit<def> = ADD32rr %vreg13:sub_32bit, %EAX<kill>, %EFLAGS<imp-def,dead> %EAX will be added to usedPregSet when the instruction is encountered, but %vreg13 is a different class (64bit registers), so none of its candidates will conflict. In addition to checking membership of usedPregSe...

Lang - Your fix does prevent the assembler errors, but it doesn't seem to produce correct assembly. I created a slightly modified version that, for each instruction that includes a vreg, adds a check that the preg selected is not already in that instruction. I've attached that version. I think that this version of Gcra.cpp should produce correct assembler, since it's allocating

Hi Susan, The problem is that the allocator is re-using the 'preg', which is calculated for an operand that may have a subreg index, for loads and stores to a stack-slot. The stack slot always has the same width as vreg (which is the right behavior), but for operands with subreg indexes, 'preg''s class will be different from 'vreg', in which case you get the mismatched