search for: regclasses

In our generated asm code we've got a constraint such that two registers in a ternary op have to be in different "banks", best illustrated with an example: add r1,r2,r1 # r1 <- r2 + r1 The problem here is that the first operand (the receiver of the value) is in the same "bank" as the 3rd operand (r1 again). This will cause an extra cycle to be burned. As it turns

...t 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 destination regclasses are identical. > Right now the x86 target code has to explicitly spell out where > such copies are needed. It isn't a lot of trouble because there are > a small number of situations where copies are needed. From your > description, it sounds like this would be much more significa...

Che-Liang Chiou <clchiou at gmail.com> writes: > My purpose is to eliminate copy-paste style of programming in td files > as much as possible, but only to a point that the new language > constructs do not create too much overhead/readability-downgrade. Yes! > In other words, I am targeting those low-hanging fruit of copy-paste > programmings in td files that are eliminated

...ckpropagate and > so doesn't influence the allocation class. The coalescer has the capability to coalesce cross register class copies. It's not quite done. Try -join-cross-class-copies. > > PBQP doesn't even attempt to remove a move unless source and > destination > regclasses are identical. > >> Right now the x86 target code has to explicitly spell out where >> such copies are needed. It isn't a lot of trouble because there are >> a small number of situations where copies are needed. From your >> description, it sounds like this would be...

Hi Jakob and David, The for-loop inside multiclass definition does not have to add extra abstraction layer. As in the pseudo codes that David wrote earlier (see below), it only condenses the repetitive 'def' statements inside the multiclass definition into a more compact and less copy-paste style form, instead of encapsulating them somewhere outside the multiclass definition. I believe

On Oct 8, 2011, at 6:19 AM, Che-Liang Chiou wrote: > I 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

David and Che-Liang, thank you for your hard work on this. Let me clarify what we may accept and what we cannot. Che-Liang, we cannot accept TGPreprocessor. Please revert it as soon as possible. The for-loop syntax is still being discussed, it's not yet clear what we will end up accepting. Please work with Jakob on this. David, we cannot accept the 'multidef' keyword. Please revert

On Fri, Oct 7, 2011 at 11:05 PM, David A. Greene <greened at obbligato.org> wrote: > Che-Liang Chiou <clchiou at gmail.com> writes: > >> My purpose is to eliminate copy-paste style of programming in td files >> as much as possible, but only to a point that the new language >> constructs do not create too much overhead/readability-downgrade. > > Yes! >

...> > 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 changed to P everything would work. > > The solution is not always that simple. There could be multiple uses > with different regclasses, or the def and use regclasses could be > disjoint so a reg-to-reg copy would be necessary. > > Am I misusing register classes, or is this simply functionality that > has > not been written yet? The existing backends seem to have only one > register class per machine value type....

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

My purpose is to eliminate copy-paste style of programming in td files as much as possible, but only to a point that the new language constructs do not create too much overhead/readability-downgrade. In other words, I am targeting those low-hanging fruit of copy-paste programmings in td files that are eliminated by a simple for-loop syntax. The repetitive patterns I observed in PTX backend (and

...(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 changed to P everything would work. The solution is not always that simple. There could be multiple uses with different regclasses, or the def and use regclasses could be disjoint so a reg-to-reg copy would be necessary. Am I misusing register classes, or is this simply functionality that has not been written yet? The existing backends seem to have only one register class per machine value type. Regards, /stoklund

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

On Oct 6, 2011, at 12:42 PM, David A. Greene wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: >> >>> For example, I want to be able to do this: >>> >>> defm MOVH : >>> vs1x_fps_binary_vv_node_rmonly< >>> 0x16, "movh", undef, 0, >>>

2016-12-20 22:14 GMT+08:00 Tom Stellard <tom at stellard.net>: > > 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

greened at obbligato.org (David A. Greene) writes: > Also, I know I introduced the #..# "pasting" operation but I've found it > to be too limiting. In this example: [snip!] > what if we instead did this: > > (Equivalent TableGen code with a for-loop) > ---------------------------------------- > multiclass PTX_FLOAT_4OP<string opcstr, SDNode opnode1, SDNode

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

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 :

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