search for: legalize

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

Right. DAGCombine will insert *illegal* nodes before legalize. Evan On Jan 19, 2009, at 8:17 PM, Eli Friedman wrote: > On Mon, Jan 19, 2009 at 6:36 PM, Scott 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 &...

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

...h 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 strange sized values in the source of G_EXTRACT/G_SEXT etc, and then just set the register class as the type information isn’t really needed anymore. However,...

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 yesterday, here is quick summary: One problem that some of us are seeing in the legalizer is that sometimes instructio...

...s 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 gmail.com> napisał: > ReplaceNodeResults is called by the type legalizer for custom legalizing > any of the results of a node that have an illegal type. > > LowerOperation is 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...

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

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". For example, let's look at G_ICMP and G_SELECT. In llvm IR type of result of icmp is always i1, and test a...

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? >&g...

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

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

...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 TargetLowering callback method we use. For example, Custom will let it through to instructions selection, which it breaks at the that phase, otherwise I believe it breaks during legalization. If we use Expand instead, the assert during Legalize is: "EXTLOAD should alw...

...x) version and _ZGVdN4v_sin (avx2) versions. Following the SVML path adding new entry in VecDesc structure in TargetLibraryInfo.cpp, we can generate the vector version. But unable to decide which version to expand in the vectorizer. We needed the TTI information (ISA ). It looks like better to legalize or generate them later. regards, Venkat. On 30 June 2018 at 04:04, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org > wrote: > Hi Hideki - > > I hinted at this problem in the summary text of https://reviews.llvm.org/ > D47610: > Why are we transforming from LLVM intrin...

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 infrastructure. So you woul...

...ve to custom >>> lower all other i16 operations. This will work, but it requires a lot >>> of target specific code. >> >> True. If we add the i16 reg class we will need to write a lot of >> target specific code. >> To avoid that our idea was not to tell the legalizer about the i16 >> regclass and let it expand everything but ignore the pointers. > > You can try just marking all i16 operations, other than load and > store, as "expand". Would that work? Won't work; LLVM expects at least some basic operations, like add, to be legal i...

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

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