search for: legalization

Duncan: DAGCombine is inserting an IllegalOperation after target-specific instruction legalization has occurred. I'm inserting the fabs and the bitconvert during instruction legalization; DAGCombine is converting the fabs/bitconvert to an 'and' on its second (third?) pass. -scooter On Jan 20, 2009, at 12:24 AM, Duncan Sands wrote: > On Tuesday 20 January 2009 07:52:37 Evan...

...the >> right thing for CellSPU and it's damed difficult to work around this >> "feature". Moreover, the way all of SelectionDAGLegalize and >> DAGCombne's code is written, it's particularly difficult to "re- >> legalize" nodes unless one more legalization pass is invoked after >> DAGCombine. > > I don't think DAGCombine should be doing a transform like that > post-legalize; if it is, it's probably a bug. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiu...

On Tuesday 20 January 2009 07:52:37 Evan Cheng wrote: > Right. DAGCombine will insert *illegal* nodes before legalize. There are two stages of legalization: legalization of types, followed by legalization of operations. Before type legalization DAGCombine is allowed to create nodes with illegal types and illegal operations. After type legalization but before operation legalization it is allowed to create nodes with illegal operations, but all types...

Hi, I’m trying to handle some vector operations with splitting/scalarization and keep running into similar sorts of issues which are making me question the intended function of the various legalization operations (particularly G_MERGE_VALUES/G_UNMERGE_VALUES, but also G_EXTRACT/G_INSERT and conversion instructions) and what the contract between the legalizer and selector actually is. For scalar values, things seem clearer, but I’m still confused. The AArch64 selector code seems content to allow...

...er is that sometimes instructions get expanded before they get folded away in the combiner. IIRC Matt sees this happening with division, while I am seeing something similar with unmerge. To my particular problem: due to the nature of the architecture I'm working with, we have pretty strict legalization rules. One example is that we only allow unmerges from 64 to 32 bit. Unmerges of 32-bit or less get lowered to bit-arithmetic. However if we would do the same for anything bigger than 64-bit, the legalization of the resulting bit arithmetic would introduce illegal unmerges again, which then cau...

...called by the type legalizer to custom legalize node > inputs that have an illegal type. I believe technically it calls > LowerOperationWrapper, but that forwards to LowerOperation by default. > > LowerOperation is also called for custom legalizing nodes with legal types > after type legalization by both the vector op legalizer and the DAG > legalizer. In those cases LowerOperation is called directly and does not > call LowerOperationWrapper. > > On Tue, Jan 28, 2020 at 9:10 AM Przemyslaw Ossowski via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, &gt...

Hello, In the combine 2 step (after legalization), in the DAGCombiner::visitBIT_CONVERT() method, the DAG combiner is replacing an FABS followed by a BIT_CONVERT, to a BIT_CONVERT followed by an AND 0x7FFFFFFFFFFFFFFF. Everything is 64 bit. On my target, FABS and BIT_CONVERT are legal in 64 bit, but AND in not legal in 64 bit (is declared custom)...

Hello, I am developing GlobalISel for MIPS. I have a few questions and observations about defining legality of generic instruction and also possible combining of instructions and artifacts in pre/post legalizer combiner or elsewhere (e.g. in some sort of instruction-select patterns). I look at legality as "If generic instruction can be selected into machine instruction, it is legal".

I've been working on a backend for a 16-bit microcontroller and I've just updated my base from LLVM 3.4 to LLVM 3.5.0. This threw up a regression failure in my test suite, and having tracked down the cause, I'm now confused about the DAG legalization and optimization process which I thought I understood. I'd be really grateful for advice on whether I've misunderstood how legalization works. The target doesn't support MUL but does support i8 and i16 UMUL_LOHI and SMUL_LOHI. I custom lower i16 MUL because it's possible to use i8...

...man > <eli.friedman at gmail.com> wrote: > >> On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> >>> Can you explain why you chose the approach of using a new pass? >>> >>> I pictured removing LegalizeDAG's type legalization code would >>> >>> mostly consist of finding all the places that use TLI.getTypeAction >>> >>> and just deleting code for handling its Expand and Promote. Are you >>> >>> anticipating something more complicated? >>> >> >> &g...

...from there. https://reviews.llvm.org/D19544 There, I see Hal's review comment "let's start only with the directly-legal calls". Apparently, what we have right now in the trunk is "not legal enough". I'll work on the patch to stop bleeding while we continue to discuss legalization topic. I suppose 1) LV only solution (let LV emit already legalized VECLIB calls) is certainly not scalable. It won't help if VECLIB calls are generated elsewhere. Also, keeping VF low enough to prevent the legalization problem is only a workaround, not a solution. 2) Assuming that...

..._width(8) for (i=0;i<N;i++){ a[i] = sin(i); } } Currently, this results in a call to <8 x double> __svml_sin8(<8 x double>) after the vectorizer. This is 8-element SVML sin() called with 8-element argument. On the surface, this looks very good. Later on, standard vector type legalization kicks-in but only the argument and return data are legalized. vmovaps %ymm0, %ymm1 vcvtdq2pd %xmm1, %ymm0 vextractf128 $1, %ymm1, %xmm1 vcvtdq2pd %xmm1, %ymm1 callq __svml_sin8 vmovups %ymm1, 32(%r15,%r12,8) vmovups %ymm0, (%r...

LLVM's type legalizer is changing the types of BUILD_VECTORs in a way that seems wrong to me, but I'm not sure if this is a bug or if some targets may be relying on it. On a 32-bit target, the default action for legalizing i8 and i16 types is to promote them. If you then have a BUILD_VECTOR to construct a legal vector type composed of i8 or i16 values, the type legalizer will

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

Ahmed, Yes, this is the case, I'm sure many other 'spots' in DAGCombiner use this same check or use a similar check with LegalOperations. It just seems like bad form to have core code that generates an illegal node that legalization cannot seem to handle, unless I'm missing something, which is entirely possible. Potentially we are using the wrong LegalAction, though each I've tried breaks at different points so I don't think that's it. Yes, it is breaking during the legalize phase, depending on which TargetLo...

...views.llvm.org/D19544 >> >> There, I see Hal’s review comment “let’s start only with the >> directly-legal calls”. Apparently, what we have right now >> >> in the trunk is “not legal enough”. I’ll work on the patch to stop >> bleeding while we continue to discuss legalization topic. >> >> >> >> I suppose >> >> 1) LV only solution (let LV emit already legalized VECLIB calls) is >> certainly not scalable. It won’t help if VECLIB calls >> are generated elsewhere. Also, keeping VF low enough to prevent the >> legali...

...ve another query related to type legalizer. > > Can a target ignore certain nodes during legalize? Probably a hook for > > target that can be called inside IgnoreNodeResults ()? > > while this could be done, I don't like the idea of doing an end-run > around the whole type legalization infrastructure. So you would have > to come up with a pretty convincing argument as to why this can't be > done another way! > > > We want to keep certain nodes illegal, especially the pointer nodes. > > Our target has 16-bit pointer and a few 16-bit insns to perform &gt...

On Thu, Oct 2, 2008 at 7:34 AM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Oct 2, 2008, at 2:01 AM, sanjiv gupta wrote: > >> >>> >>> So you have a i16 register class which makes the type legal. You can >>> make loads and stores legal (can you?). But you will have to custom >>> lower all other i16 operations. This will work, but it

...thing but it's not doing the right thing for CellSPU and it's damed difficult to work around this "feature". Moreover, the way all of SelectionDAGLegalize and DAGCombne's code is written, it's particularly difficult to "re- legalize" nodes unless one more legalization pass is invoked after DAGCombine. It's not like it's actually easy to load an i64 constant while maintaining the vector register uniformity that CellSPU expects. In fact, there're a lot of different ways to load a 64-bit constant depending on the constant's value. At worse...

...it looked much cleaner > (although I didn't test it extensively). Our target is btver2, so I > also didn't look at what could have been codegen for targets with no > AVX/SSE4.1 where there might be fewer opportunities to match a shuffle > with a single target instruction during legalization. > > > > > All of my benchmarks have come back performance neutral overall with a > few > > benchmarks improving. However, there may be some regressions that folks > want > > to track down first. I'd really like to get those reported and prioritize > > amo...