search for: legality

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

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 >> (and (bitconvert val),

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

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

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

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

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

On May 20, 2009, at 9:14 PM, Eli Friedman wrote: > On Wed, May 20, 2009 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

Ashutosh, Thanks for the repy. Related earlier topic on this appears in the review of the SVML patch (@mmasten). Adding few names 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

Illustrative Example: clang -fveclib=SVML -O3 svml.c -mavx #include <math.h> void foo(double *a, int N){ int i; #pragma clang loop vectorize_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,

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

...E, G_SELECT, G_EXTRACT, and G_INSERT. There are also other configurations where integer and floating point instructions of the same size are not simultaneously available. This problem was already addressed here http://lists.llvm.org/pipermail/llvm-dev/2017-July/114978.html for G_LOAD/G_STORE. Legality of an instruction should not depend on surrounding instructions. Because of that, approach from regbankselect that iterates through uses of G_LOAD def register and checks if some of the uses was an generic floating point instruction should not be an option for legalizer. Since GlobalISel Legali...

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

Adding to Ashutosh's comments, We are also interested in making LLVM generate vector math library calls that are available with glibc (version > 2.22). reference: https://sourceware.org/glibc/wiki/libmvec Using the example case given in the reference, we found there are 2 vector versions for "sin" (4 X double) with same VF namely _ZGVcN4v_sin (avx) version and _ZGVdN4v_sin

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

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 <chandlerc at gmail.com> > wrote: > > Greetings LLVM hackers and x86 vector shufflers! > > > >...