search for: regclass

...We've got this in our specialized ArchInstrInfo.td: // r1 = r2 op r3 // class ArithOp_RR< bits<7> op, string instr_asm, SDNode opNode, OperandInfo info, InstrItinClass itin > : FR3< op, (outs info.regClass:$r1), (ins info.regClass:$r2, info.regClass:$r3), instr_asm # "\t\t$r1, $r2, $r3, " # info.sizeStr, [(set info.regClass:$r1, (opNode info.regClass:$r2, info.regClass:$r3))], itin > { let isFloat = info.isFloat; let opsize = info.sizeC...

...O(i1_s); R1 = B[P0] (Z); R2 = 1 (X); P0 = R0; R0 = R1 & R2; B[P0] = R0; RTS; The moves (P0 = R0) did not get optimized away by the register allocator. RALinScan::attemptTrivialCoalescing almost succeeded; it got as far as testing if the source register R0 is contained in the destination regclass (P). It isn't, so the move stayed in. The problem is that the source register is allocated before coalescing is attempted. The destination regclass does not backpropagate and so doesn't influence the allocation class. PBQP doesn't even attempt to remove a move unless source and dest...

...te programming > that I observed. > * It is simple enough to understand and maintain, at least I believe so. I mostly agree with these. One other thing I've found useful is the ability to abstract out the type information. For example, in x86 land, an SSE/AVX add is always: (set (type regclass:reg), (type (add (type regclass:reg), (type regclass:reg)))) Similarly, a sub is: (set (type regclass:reg), (type (sub (type regclass:reg), (type regclass:reg)))) In fact most binary operations are: (set (type regclass:reg), (type (op (type regclass:reg), (type regclass:reg)))) So why write hu...

...0; > R0 = R1 & R2; > B[P0] = R0; > RTS; > > The moves (P0 = R0) did not get optimized away by the register > allocator. RALinScan::attemptTrivialCoalescing almost succeeded; it > got > as far as testing if the source register R0 is contained in the > destination regclass (P). It isn't, so the move stayed in. > > The problem is that the source register is allocated before coalescing > is attempted. The destination regclass does not backpropagate and > so doesn't influence the allocation class. The coalescer has the capability to coalesce cross...

...understand if you don't want an extra layer of abstraction (which adds extra looking-ups to someone reading td files), but I think we can have for-loop inside a multiclass without abstractions. -------------------- multiclass sse_binop<opcode> { for type = [f32, f64, v4f32, v2f64] regclass = [FP32, FP64, VR128, VR128] suffix = [ss, sd, ps, pd] { def !toupper(suffix)#rr : Instr< [(set (type regclass:$dst), (type (opcode (type regclass:$src1), (type regclass:$src2))))]>; def !toupper(suffix)#rm : Instr< [(set...

...an extra layer of abstraction (which > adds extra looking-ups to someone reading td files), but I think we > can have for-loop inside a multiclass without abstractions. > > -------------------- > multiclass sse_binop<opcode> { > for type = [f32, f64, v4f32, v2f64] > regclass = [FP32, FP64, VR128, VR128] > suffix = [ss, sd, ps, pd] { > > def !toupper(suffix)#rr : Instr< > [(set (type regclass:$dst), (type (opcode (type regclass:$src1), > (type regclass:$src2))))]>; > def !toupper(suffix)#...

...d. >> * It is simple enough to understand and maintain, at least I believe so. > > I mostly agree with these. One other thing I've found useful is the > ability to abstract out the type information. For example, in x86 land, > an SSE/AVX add is always: > > (set (type regclass:reg), (type (add (type regclass:reg), (type regclass:reg)))) > > Similarly, a sub is: > > (set (type regclass:reg), (type (sub (type regclass:reg), (type regclass:reg)))) > > In fact most binary operations are: > > (set (type regclass:reg), (type (op (type regclass:reg),...

...ved. >> * It is simple enough to understand and maintain, at least I believe so. > > I mostly agree with these.  One other thing I've found useful is the > ability to abstract out the type information.  For example, in x86 land, > an SSE/AVX add is always: > > (set (type regclass:reg), (type (add (type regclass:reg), (type regclass:reg)))) > > Similarly, a sub is: > > (set (type regclass:reg), (type (sub (type regclass:reg), (type regclass:reg)))) > > In fact most binary operations are: > > (set (type regclass:reg), (type (op (type regclass:reg), (ty...

...external global i1 > @i1_s = external global i1 > > define void @i1_ls() nounwind { > %tmp = load i1* @i1_l > store i1 %tmp, i1* @i1_s > ret void > } > > Instruction selection works correctly, but the scheduling step fails > with "Register class of operand and regclass of use don't agree!" in > ScheduleDAGSDNodes::AddOperand. The selected DAG contains: > > (LOAD32p_8z (LOAD32imm (tglobaladdr "i1_l"))) > > LOAD32imm produces a GR-class vreg, and LOAD32p_8z expects a P-class > vreg, hence the error. But P is a subclass of GR,...

Reframing and Reposting my earlier query: My target has 16-bit registers for indirect address of data. All other registers are 8-bit. Therefore I have added regclasses for i8 and i16 types. All arithmetic operations (including pointer arithmetic ) are 8-bit operations. The problem is that LLVM does not expand i16 operations to i8 operations in presence of i16 regclass. What is the best way to tackle this? Do I need to custom lower arithmetic operations duri...

...to do this: >>>> >>>> defm MOVH : >>>> vs1x_fps_binary_vv_node_rmonly< >>>>   0x16, "movh", undef, 0, >>>>          // rr >>>>          [(undef)], >>>>          // rm >>>>          [(set DSTREGCLASS:$dst, >>>>                (DSTTYPE (movlhps SRCREGCLASS:$src1, >>>>                                (DSTTYPE (bitconvert >>>>                                            (v2f64 (scalar_to_vector >>>>                                                      ...

...e when I try to compile this function: @i1_l = external global i1 @i1_s = external global i1 define void @i1_ls() nounwind { %tmp = load i1* @i1_l store i1 %tmp, i1* @i1_s ret void } Instruction selection works correctly, but the scheduling step fails with "Register class of operand and regclass of use don't agree!" in ScheduleDAGSDNodes::AddOperand. The selected DAG contains: (LOAD32p_8z (LOAD32imm (tglobaladdr "i1_l"))) LOAD32imm produces a GR-class vreg, and LOAD32p_8z expects a P-class vreg, hence the error. But P is a subclass of GR, so if the vreg class were...

Ok, I've found that marking tiny live intervals as not spillable inside VirtRegAuxInfo::CalculateWeightAndHint is not playing nicely with very constrained regclasses, in my case a regclass composed of only one register. As a workaround, instead of marking them as not spillable, I've marked them with a very high spill cost and the regalloc is able to compile the function with good code quality. To avoid doing this for all live intervals of this regclass, I...

...For example, I want to be able to do this: >>> >>> defm MOVH : >>> vs1x_fps_binary_vv_node_rmonly< >>> 0x16, "movh", undef, 0, >>> // rr >>> [(undef)], >>> // rm >>> [(set DSTREGCLASS:$dst, >>> (DSTTYPE (movlhps SRCREGCLASS:$src1, >>> (DSTTYPE (bitconvert >>> (v2f64 (scalar_to_vector >>> (loadf64 addr:$...

...Hi Tom, I take a look at the code, it looks like a good idea. It really helps me a lot. Thanks Tom! I have a question for the code, why it only pass copy-like instructions as TopInst to moveToALU()? Is there any special reason to do like this? I thought that iterating through all the MIs and fix regClass if needed would be ok. Am I thinking it too simple? - Ruiling > > -Tom > > > - Ruiling -- - Ruiling -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161221/62bf3cc9/attachment.html>

...s. Here's some more detail on this. I want to be able to use #..# pasted stuff in a variety of contexts. For example: multiclass blah<string intr> { for prefix = [<empty>, Vx, Vy] { for suffix = [ps, pd] { def #prefix#ADD#suffix# : ProcessSomePattern< [(set RegClass:$dst, (!cast<Intrinsic>(#prefix#intr#suffix) RegClass:$src1, RegClass:$src2))] } } } It's actually more complex than this but this gives the basic idea. The key thing I need to be able to do is construct an instrinsic name given some base string, a pr...

On Tue, Dec 20, 2016 at 11:00:09AM +0800, Ruiling Song wrote: > Hi, > > I am working on a new LLVM target for Intel GPU, which also has same kind > of scalar/vector register classes used in AMDGPU target. Like for a i32 > virtual register, it will be held in scalar register if its value is > uniform across a wavefront/warp, otherwise it will be in a vector register. > Does

Hello, About a month ago, I submitted a set of patches for review on llvm-commit. The most controversial of the patches, http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20150622/d104ea7 1/attachment-0009.obj deals with the fact that before ARMv8, the rGPR RegClass in Thumb encodings didn't include SP; but from ARMv8 onwards, it does include it. RegClass membership is currently implemented as entirely static, driven by read-only TableGen'd tables and switch blocks encoding the various classes, subclasses, and their relationships. The approach I ha...

Chris Lattner wrote: > However, I don't see any reason to base this off of strings. Instead > of passing down "f32" as a string, why not do something like this > pseudo code: > > class X86ValueType { > RegisterClass RegClass; > ... > } > > def X86_f32 : X86ValueType { > let RegClass = FR32; > ... }; > def X86_i32 : X86ValueType { ... }; > > Then change fp_cvt_scalar_VXSnrr to be something like this: > >> class fp_cvt_scalar_VXSnrr< >> // Parent: avx_fp_cvt_scalar...

On Jan 9, 2013, at 10:46 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Ok, I've found that marking tiny live intervals as not spillable inside VirtRegAuxInfo::CalculateWeightAndHint is not playing nicely with very constrained regclasses, in my case a regclass composed of only one register. > As a workaround, instead of marking them as not spillable, I've marked them with a very high spill cost and the regalloc is able to compile the function with good code quality. To avoid doing this for all live intervals of this regcl...