similar to: [LLVMdev] Type Legalizer - Load handling problem

On Mon, 2008-08-18 at 08:50 -0700, Eli Friedman wrote: > On Mon, Aug 18, 2008 at 6:31 AM, <Sachin.Punyani at microchip.com> wrote: > > assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 && > > "Invalid operand expansion"); > > > > LOAD node has two values but the assertion checks N->getNumValues() == 1 >

On Tue, Aug 19, 2008 at 8:07 AM, sanjiv gupta <sanjiv.gupta at microchip.com> wrote: > On Mon, 2008-08-18 at 08:50 -0700, Eli Friedman wrote: >> On Mon, Aug 18, 2008 at 6:31 AM, <Sachin.Punyani at microchip.com> wrote: >> > assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 && >> > "Invalid operand

On Mon, Aug 18, 2008 at 6:31 AM, <Sachin.Punyani at microchip.com> wrote: > assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 && > "Invalid operand expansion"); > > LOAD node has two values but the assertion checks N->getNumValues() == 1 > which is not letting us change load operation. I don't really know the

Hi, > How will LOAD:i8 with an i16 operand be lowered in type legalizer? (i16 > type is not legal for our target) what does "LOAD:i8 with an i16 operand" mean? Are you saying that the type of a pointer is i16, and you are loading an i8 value from the pointed to location? If so, you are in trouble because many parts of the code generator assume that the type of a pointer is

On Tue, Aug 19, 2008 at 8:40 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Aug 19, 2008 at 8:07 AM, sanjiv gupta > <sanjiv.gupta at microchip.com> wrote: >> On Mon, 2008-08-18 at 08:50 -0700, Eli Friedman wrote: >>> On Mon, Aug 18, 2008 at 6:31 AM, <Sachin.Punyani at microchip.com> wrote: >>> > assert(Res.getValueType() ==

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

Hi, I am trying to write a LowerCALL() function for my (custom) target ISA. All I need to do is map a CALL instruction directly onto an SDNode that takes an equal number of arguments (very much alike intrinsics, except that these are custom to my target.) I do not need to implement any call sequences, stack frames etc. I get the following assertion failure: llc: LegalizeDAG.cpp:834:

Hello Evan and Robert I have been investigating the unexpected test failures from the ARM nightly builders in order to get a better picture why the ARM backend don't pass the whole testsuite: I have run the failing tests manually on my arm board and can now categorize most of the thirteen unexpected CodeGen failures in four categories: 1. llvm don't lower MVT::i64 properly on arm

Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT =

Hi Nickhil, The Legalizer expects lower'd call is the node that produce the same number of values as the non-lowered node. That's what the assertion is checking. Take a look at the LowerCall routine for any other targets. You will see that in the non-void function case, it returns a MERGE_VALUES, i.e. all the results merged along with the chain. Cheers, Evan On Nov 15, 2006, at

> > LOAD node has two values but the assertion checks N->getNumValues() == 1 > > which is not letting us change load operation. > > Yup, in this case you need to return an SDValue with null Val field, > and take care of replacing values yourself. That said, it looks like it is done this way because no-one needed anything more. It could easily be changed to handle the

v4i8 itself is a legal type, just not on the 'AND' operation. So there seems to be multiple problems here. 1) PromoteVectorOp doesn't handle the case where the types are not the same size, this occurs because #2 2) getTypeToPromoteTo doesn't actual check to see if the type it should promote to makes any sense. 3) PromoteVectorOp also doesn't handle the case where

Notice that PromoteVectorOp is called after the type legalization legalized all of the types in the program. It legalizes the *operations*, not the types. So, you should only see legal types (Legal types are types that fit into your registers). So, if your target has v2i32, I suspect that v4i8 is an illegal because it has a different size. -----Original Message----- From: Villmow, Micah

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

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

If v4i8 is a legal type then getTypeToPromoteTo should return the pair v4i8 and 'legal'. This looks like the root of the problem. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 22:10 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> v4i8 itself is a legal type, just not

Hi, When expanding multiply operation in LegalizeTypes LLVM generates some nodes such as UMUL_LOHI (please refer file LegalizeIntegerTypes.cpp - function - ExpandIntegerResult). However while lowering this operation in LegalizeDAG (please refer file LegalizeDAG.cpp - function - LegalizeOp) the comment says "These nodes will only be produced by target-specific lowering.....".

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Bill Wendling > Sent: Friday, September 19, 2008 4:38 AM > > On Thu, Sep 18, 2008 at 7:12 AM, <Sachin.Punyani at microchip.com> wrote: > > What changes would be required in LLVM to support illegal pointer type? > > > Hi Sachin, >

I don't know how your target architecture looks like, but I suspect that <4 x i8> should not be legalized to <1 x i32>. I think that what you are seeing is that <4 x i8> is first split into <2 x i8>, and later promoted to <2 x i32>. At the moment different targets can only affect type-legalization by declaring different legal types. A number of us discussed the

LLVM ARM v6 backend is in fairly good shape. Even the JIT passes nearly the entire llvm test suite. There are some known missing bits: 1. Exception handling 2. Atomic Not sure: 3. Debugging support (should be trivial to hook up if it's not done) Also the thumb backend is not awesome. Its performance is not great. Evan On Apr 1, 2009, at 6:34 AM, Robert Schuster wrote: > Hi, > the