similar to: [LLVMdev] 32bit math being promoted to 64 bit

On Dec 4, 2008, at 8:58 AM, Villmow, Micah wrote: > What optimization pass promotes 32 bit math operations to 64 bit > operations so I can disable it? I have code that works fine with > optimizations turned off but fails with it turned on because of this > stage. > Do you have a testcase? An .ll file with no 64-bit operations, and one optimization pass that introduces

On Thu, Dec 4, 2008 at 7:08 PM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 4, 2008, at 8:58 AM, Villmow, Micah wrote: > > What optimization pass promotes 32 bit math operations to 64 bit operations > so I can disable it? I have code that works fine with optimizations turned > off but fails with it turned on because of this stage. > > > Do you have a

instcombine doesn't seem to be doing it. From my testing it seems to only occur when I use -indvars after a long string of commands. For example: llvm-as < test_fc_27.ll | opt -preverify -domtree -verify -lowersetjmp -raiseallocs -simplifycfg -domtree -domfrontier -mem2reg -globalopt -globaldce -ipconstprop -deadargelim -instcombine -simplifycfg -ba siccg -prune-eh -inline

> Do you have a testcase? An .ll file with no 64-bit operations, and one > optimization pass that introduces them? It's pretty common to instcombine to expand 32 bit operations to 64 bit. See, for example, recent issue with CellSPU's 32 =>64 bit muls -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

I have the following function: define void @test_fc_0_kernel(i16 signext %x, i16 signext %y, i16 addrspace(11)* %input, i32 addrspace(11)* %result) { entry: %call = tail call i32 @get_id(i32 0) ; <i32> [#uses=2] %cmp = icmp slt i16 %x, %y ; <i1> [#uses=1] br i1 %cmp, label %if.then, label %if.end

On Thu, Feb 12, 2009 at 4:53 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > The > problem that I am having is somewhere along the line the 16bit load is being > promoted to a 32bit load For the given testcase, that's clearly illegal. Either there's a serious bug in LLVM, or you're misinterpreting the meaning of the DAG. Are you sure you aren't seeing a

Sorry, <4 x i8> should convert to a <1 x i32>. What currently is happening is that it is returning a <2 x i32> because <1 x i32> does not exist. Micah > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Monday, July 30, 2012 10:51 AM > To: Villmow, Micah; Developers Mailing List > Subject: RE: Vector promotion broken

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 =

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

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith Sent: Wednesday, September 12, 2012 3:30 PM To: Villmow, Micah Cc: Eli Friedman; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [cfe-dev] [LLVMdev] SPIR Portability Discussion On Wed, Sep 12, 2012 at 3:26 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote:

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

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

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

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Wednesday, September 12, 2012 3:22 PM > To: Villmow, Micah > Cc: Richard Smith; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [cfe-dev] [LLVMdev] SPIR Portability Discussion > > On Wed, Sep 12, 2012 at 2:58 PM, Villmow, Micah <Micah.Villmow at amd.com> >

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Wednesday, September 12, 2012 3:50 PM > To: Villmow, Micah > Cc: Richard Smith; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [cfe-dev] [LLVMdev] SPIR Portability Discussion > > On Wed, Sep 12, 2012 at 3:40 PM, Villmow, Micah <Micah.Villmow at amd.com> >

The comments in the code state it should do bitcast, op, then bitcast, not extend, op and truncate. "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." So following the same logic <4 x i8> bitcasts into a

"Villmow, Micah" <Micah.Villmow at amd.com> writes: > Sorry, <4 x i8> should convert to a <1 x i32>. Why? I'm really confused. Shouldn't this converts to a <4 x i32>? -Dave

On Wed, Sep 12, 2012 at 3:26 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > > > > -----Original Message----- > > From: Eli Friedman [mailto:eli.friedman at gmail.com] > > Sent: Wednesday, September 12, 2012 3:22 PM > > To: Villmow, Micah > > Cc: Richard Smith; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > > Subject: Re: [cfe-dev] [LLVMdev]

On Wed, Sep 12, 2012 at 3:40 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > ** ** > > ** ** > > *From:* metafoo at gmail.com [mailto:metafoo at gmail.com] *On Behalf Of *Richard > Smith > *Sent:* Wednesday, September 12, 2012 3:30 PM > *To:* Villmow, Micah > *Cc:* Eli Friedman; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > > *Subject:* Re:

On Wed, Sep 12, 2012 at 3:40 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > > > > From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard > Smith > Sent: Wednesday, September 12, 2012 3:30 PM > To: Villmow, Micah > Cc: Eli Friedman; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > > > Subject: Re: [cfe-dev] [LLVMdev] SPIR