search for: g_constant

...known limitation that we’ve discussed in https://reviews.llvm.org/D59227 <https://reviews.llvm.org/D59227> but we didn’t really reach a conclusion back them. > Short term, I believe you’re right, we should patch up the GISel emitter to use getConstantVRegVal instead of looking directly for G_CONSTANT. That's not as easy as you make it sound :-) but let's suppose we can recognize enough of the underlying pattern to be able to use getConstantVRegVal() instead of needing to do a direct translation of the SelectionDAG pattern. In the SelectionDAG patterns an ImmLeaf is an `imm` node with a...

...on an off-tree architecture and am thinking I must be doing something wrong, given by how few things actually work. Namely, any ImmLeaf pattern will fail to match if there is a (TRUNC/ZEXT/SEXT) applied to the constant operand, all of which are commonly created through Legalization. This is due to G_CONSTANT being explicitly looked for by the tablegened code, rather than code that makes use of getConstantVRegVal. Is there supposed to be a constant folding pass before Instruction Selection? CSE does not fold past unaries applied to operands, I'm surely missing a pass somewhere... Thanks, - Alex Dav...

...ething like "G_SHL %X, ${imm}", right? Why not express that directly in MIR? Going by http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/CIHBEAGE.html (which admittedly is old docs but it's unlikely to have changed), it needs to be able to match the following: %0 = G_CONSTANT iN ${imm} # Where imm is any immediate expressible using an unsigned 8-bit immediate rotated by an even number of bits %0 # I.e. just a plain vreg %0 = G_CONSTANT iN ${imm} # Where imm is 1 to 32 %2 = G_[AL]SHR %1, %0 %0 = G_CONSTANT iN ${imm} # Where imm is 0 to 31 %2 = G_SHL %1, %0 %0 = G_CON...

...tion where we emit at the point of use. As a result we run a localizer pass in an effort to reduce the live ranges of the constants (and the consequent spilling), using some heuristics to decide where to sink the constant definitions to. Since we don’t do any real caching of MI constants, multiple G_CONSTANT definitions can exist for the same constant. This can also result in a lot of redundant constants being created, especially for things like address computation. Reducing the number of constants can help reduce compile time and memory usage. Given this situation, one possible approach is to encode c...

...ive the GlobalISel perspective on this, GlobalISel supports the declaration of a zero register in the register class like so: def GPR32z : RegisterOperand<GPR32> { let GIZeroRegister = WZR; } With that definition, the tablegen-erated ISel code will try to replace will try to replace 'G_CONSTANT s32 0' with WZR whenever the operand is specified as GPR32z. > On 21 Dec 2017, at 21:22, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I looked around the codebase and didn't see anything that obviously looked like the natural place to turn constant zero i...

...supports the declaration of a zero register in the register > class like so: > def GPR32z : RegisterOperand<GPR32> { > let GIZeroRegister = WZR; > } > With that definition, the tablegen-erated ISel code will try to replace > will try to replace 'G_CONSTANT s32 0' with WZR whenever the operand is > specified as GPR32z. > Is this method extensible to the case of other hardwired register values? Tracing through the code, I noticed that it seems to boil down to a GIR_CopyOrAddZeroReg opcode, which seems like a pretty deep embedding of the spe...

...s in that sense that GlobalISel is "global". > Also, are there any examples which show that the current global isel take > information across multiple BBs within a function? I don't think any of the targets use this feature right now. The first use will probably be folding of G_CONSTANT nodes (that we currently all emit in the entry block) into immediate operands. HTH, -Ahmed > Best Regards, > -- > Bekket McClane > Department of Computer Science, > National Tsing Hua University > > _______________________________________________ > LLVM Developers mailing...

Hi, I've been studying the global instruction selector introduced recently. One of the properties of global instruction selectors is that they select instructions across basic blocks such that they can get more information in order to choose optimal patterns. However, the current global isel implementation still iterates over BBs within functions, which is same as the original SelectionDAG

...lobalISel supports the declaration of a zero register in the register class like so: > def GPR32z : RegisterOperand<GPR32> { > let GIZeroRegister = WZR; > } > With that definition, the tablegen-erated ISel code will try to replace will try to replace 'G_CONSTANT s32 0' with WZR whenever the operand is specified as GPR32z. > > > Is this method extensible to the case of other hardwired register values? Tracing through the code, I noticed that it seems to boil down to a GIR_CopyOrAddZeroReg opcode, which seems like a pretty deep embedding of th...

...gly make this work: // fold loads in to compare instructions def : Pat<(CPw_sr i32:$k, (MOVw_wf iPTR:$s)), (CPw_sf i32:$k, iPTR:$s)>; And it looks like SDNodeXForms will work off the bat, along with complex renderers. The main catches being with constants that require checking (due G_CONSTANT being handled differently to immediates), along with needing to add checks that the instruction has the same implicits, and that they're dead where appropriate. But it seems viable and is definitely easy to use so I'm just wondering... is this something that's being considered/is appeal...

I looked around the codebase and didn't see anything that obviously looked like the natural place to turn constant zero immediates into zero-registers (i.e. registers that always return zero when read). Right now we are expanding them in ISelLowering::LowerOperation but that seems too early. The specific issue I'm hitting is that we have a register that reads as -1 and so when we replace

Thanks Nicolai! > On Nov 9, 2018, at 02:55, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Hi Daniel, > > Lots of good stuff in there! I especially like the design for specifying out-of-line predicates. I have a couple of small comments and one major one below. > > > On 09.11.18 02:42, Daniel Sanders via llvm-dev wrote: >> _Passing arbitrary data from

Hi, Mips32 has 64 bit floating point instructions, while i64 instructions have to be emulated with i32 instructions. This means that G_LOAD should be custom legalized for s64 integer value, and be legal for s64 floating point value. There are also other generic instructions with the same problem: G_STORE, G_SELECT, G_EXTRACT, and G_INSERT. There are also other configurations where integer

...? This is the pattern in question: def tuimm9 : TImmLeaf<i32, [{ return isUInt<9>(Imm); }]>; def : Pat<(int_target_foo tuimm9:$mask), (FOO tuimm9:$mask)>; Match table when using TImmLeaf: GIM_CheckIsImm, Match table when using ImmLeaf: GIM_CheckOpcode, /*MI*/1, TargetOpcode::G_CONSTANT, GIM_CheckI64ImmPredicate, /*MI*/1, /*Predicate*/GIPFP_I64_Predicate_uimm9, Basically I'm wondering how I can make TableGen generate the GIM_CheckI64ImmPredicate when using TImmLeafs. Cheers, Dominik -------------- next part -------------- A non-text attachment was scrubbed... Name: smime....

...ss, so TTI is not appropriate. Reasonably implementing this would still require adding something in TableGen (which then just brings you back to adding an attribute). I would also like to be able to rely on this for emission of G_INTRINISIC_* instructions in GlobalISel, so that intermediate illegal G_CONSTANT instructions can be avoided -Matt

...lect is to produce the mapping with the overall lowest cost. Keeping track of all different combinations of mappings will certainly be non-trivial however, so I wonder if there is a smart way to do this without spending too much compilation time. Ideally for instructions with no operands (like G_CONSTANT) it could also check whether a cross-bank copy is actually worth it or if it would be more beneficial to simply rematerialize the instruction on the required bank. For such instructions this information should already be available as part of the cost-modelling in RegBankSelect: we could simply...

...ake pattern-matching more effective, and reduces register pressure in some cases). And some of our cost modeling on IR sort of depends on the fact that constants are not instructions. I mean, we don't need constants; at an extreme we could have a constantint instruction, like GlobalISel's G_CONSTANT. But it's not clear that would be helpful for midlevel optimizations. For scalable vectors in particular, currently, the only way to express a vector with where every element is a simple integer is using a splat shuffle expression, and those often fold into some instruction. Continuing to us...

...rall lowest cost. Keeping track of all different >> combinations of mappings will certainly be non-trivial however, so I >> wonder if there is a smart way to do this without spending too much >> compilation time. >> >> Ideally for instructions with no operands (like G_CONSTANT) it could >> also check whether a cross-bank copy is actually worth it or if it >> would be more beneficial to simply rematerialize the instruction on >> the required bank. For such instructions this information should >> already be available as part of the cost-modellin...

...se. As a result we run a localizer pass in an effort to reduce the >> live ranges of the constants (and the consequent spilling), using some >> heuristics to decide where to sink the constant definitions to. >> >> Since we don’t do any real caching of MI constants, multiple G_CONSTANT >> definitions can exist for the same constant. This can also result in a lot >> of redundant constants being created, especially for things like address >> computation. Reducing the number of constants can help reduce compile time >> and memory usage. Given this situation,...

...se. As a result we run a localizer pass in an effort to reduce the >> live ranges of the constants (and the consequent spilling), using some >> heuristics to decide where to sink the constant definitions to. >> >> Since we don’t do any real caching of MI constants, multiple G_CONSTANT >> definitions can exist for the same constant. This can also result in a lot >> of redundant constants being created, especially for things like address >> computation. Reducing the number of constants can help reduce compile time >> and memory usage. Given this situation,...