search for: legalized

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

...cott Michel <scottm at aero.org> wrote: >> I just ran across something interesting: DAGCombine inserts a 64-bit >> constant as the result of converting a (bitconvert (fabs val)) to a >> (and (bitconvert val), i64const). >> >> The problem: i64 constants have to be legalized for the CellSPU >> platform. DAGCombine is doing the right 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 writte...

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

...et selector supposed to be responsible for handling G_UNMERGE_VALUES/G_MERGE_VALUES/G_EXTRACT/G_INSERT/G_SEXT/G_ZEXT/G_ANYEXT for any strange type source, assuming the extra high bits over the LLT type are undefined or appropriately extended? For vectors, is any arbitrary vector only supposed to be legalized to a certain number of elements, and the target is supposed to treat this as N registers with possibly undefined high bits in NumRegBits - TypeScalarSize? Should the legalizer for some of these operations really be triggering legalization of the def instruction of the input instead? -Matt ---------...

Hi all, first of all thanks to Matt for hosting the round table yesterday and to everyone else for their time and the valuable discussions. As promised in the chat yesterday, here is the email regarding the legalizer / artifact combiner issue we talked about. I will send a separate email regarding the regbankselect discussion. In case someone on the list didn't attend the round table

Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at

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). So the dag combiner is introducing illegal (not

...? b) Is the plan to sometimes let s1 as legal type and ignore it later? c) Is the plan to sometimes let s1 as legal type and use this type as a hint to select between multiple available instructions using some patterns? For example, in https://reviews.llvm.org/D51489, G_ICMP got its result (type0) legalized as legal for s32 (corresponding to plan a)). We would get similar final output (also correct) if we said that type0 is legal for s1 (corresponding to b), but in this case it is also necessary to: tell that extends are legal for {s32, s1}, regbankselct and instruction select G_ZEXT. It would be nic...

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

...9 at 5:26 PM, Eli Friedman > <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? >&gt...

...ent "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 we have to go to IR to IR pass route, there are 3 ways to think: a....

...ently, 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, (%r15,%r12,8) Unfortunately, __svml_sin8() doesn't use this...

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 and floating point instructions of the same size are not simultaneousl...

...hmed > > > I'm guessing, from what > > you and others have said, that it's just expected that every machine will > > support 8-bit extloads and if not then the target should handle the > undoing > > of the target-independent generated 'optimization' via LegalizeDAG and > > TargetLowering callback methods? > > > > 3) I have not tried running it on any other target, sorry, I suppose I > > should but I didn't want to take the time if I'm not following the right > > path here. > > > > Thanks. > > > >...

...”. 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 we have to go to IR to IR...

On Wed, 2008-10-01 at 11:12 +0200, Duncan Sands wrote: > Hi, > > > I have 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

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

I just ran across something interesting: DAGCombine inserts a 64-bit constant as the result of converting a (bitconvert (fabs val)) to a (and (bitconvert val), i64const). The problem: i64 constants have to be legalized for the CellSPU platform. DAGCombine is doing the right 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 dif...

I ran the benchmarking subset of test-suite on a btver2 machine and optimizing for btver2 (so enabling AVX codegen). I don't see anything outside of the noise with x86-experimental-vector-shuffle-legality=1. On Fri, Jan 23, 2015 at 5:19 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com > wrote: > Hi Chandler, > > On Fri, Jan 23, 2015 at 8:15 AM, Chandler Carruth