similar to: [LLVMdev] Adding legal integer sizes to TargetData

On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote: > Now that 2.5 is about to branch, I'd like to bring up one of Scott's > favorite topics: certain optimizers widen or narrow arithmetic, > without regard for whether the type is legal for the target. In his > specific case, instcombine is turning an i32 multiply into an i64 > multiply in order to eliminate a cast. This

On Feb 2, 2009, at 1:26 PM, Dale Johannesen wrote: > > On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote: > >> Now that 2.5 is about to branch, I'd like to bring up one of Scott's >> favorite topics: certain optimizers widen or narrow arithmetic, >> without regard for whether the type is legal for the target. In his >> specific case, instcombine is

On Feb 2, 2009, at 1:29 PMPST, Chris Lattner wrote: > > On Feb 2, 2009, at 1:26 PM, Dale Johannesen wrote: > >> >> On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote: >> >>> Now that 2.5 is about to branch, I'd like to bring up one of Scott's >>> favorite topics: certain optimizers widen or narrow arithmetic, >>> without regard for

Now that 2.5 is about to branch, I'd like to bring up one of Scott's favorite topics: certain optimizers widen or narrow arithmetic, without regard for whether the type is legal for the target. In his specific case, instcombine is turning an i32 multiply into an i64 multiply in order to eliminate a cast. This does simplify/reduce the number of IR operations, but an i64 multiply

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

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), i64const). > > The problem: i64 constants have to be legalized for the CellSPU > platform. DAGCombine is doing the right thing but

Evan: And after legalize too. DAGCombine gets run after legalization. :-) -scooter On Jan 19, 2009, at 10:52 PM, Evan Cheng wrote: > 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

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 Tue, Nov 30, 2010 at 05:48, Jonas Paulsson <jnspaulsson at hotmail.com> wrote: > > May I ask then, what could one expect from various optimizations when using > intrinsics to support the fixed point type? LTO, Value optimizations, mem ?? > Can you not just lower your fixed-point operations to widen, perform normal integer operation, shift and truncate? With LLVM's

On Wed, Dec 1, 2010 at 8:11 AM, me22 <me22.ca at gmail.com> wrote: > On Tue, Nov 30, 2010 at 05:48, Jonas Paulsson <jnspaulsson at hotmail.com> wrote: >> May I ask then, what could one expect from various optimizations when using >> intrinsics to support the fixed point type? LTO, Value optimizations, mem ?? >> > > Can you not just lower your fixed-point

Eli: Legal constants would be all well and good for most platforms. I don't think that CellSPU is alone in its support for i64 constants (in fact, the comment in DAGCombine says that the 64-bit constant is inserted to "avoid a constant pool spill"). In many respects, DAGCombine and operation Legalize are co-routines, not separate passes. -scooter On Jan 20, 2009, at 1:23

Hello, Is there any way for a pass to determine the L1 or L2 cacheline size of the target before the IR is lowered to machine instructions? Thanks, -- Nick Johnson

I think your users will be very upset if you don't set the boolean return value correctly :-) Whatever work it takes to determine the correct value for it, if the user code doesn't need/use that value then the dead code will be eliminated later. But if they need that return flag then they will want it to be correct! You may need to use a multiply instruction that returns a

If your target has a cheap count-leading-zeros instruction, you'd be able to determine whether an unsigned multiply will overflow or not, in most cases, without doing the long version of the multiplication. This is because an N-bit number times an M-bit number will produce a result that is either N+M bits wide or N+M-1 bits wide. If an N+M bit result will fit in your result type, you are

Hi Nadav, I believe the implementation to keep on widening the vector to the next power of two must be in TargetLowering.h because that is where we decide whether to Widen the vector or not, and the size to which we widen it. In this case, we stop at 4xi8 and do not check if it is legal or not. But the comment says ‘try to widen vector elements until a legal type is found’. Also, there is a

On Aug 13, 2013, at 9:09 AM, Sriram Murali <sriram87 at gmail.com> wrote: > Hi Nadav, I believe the implementation to keep on widening the vector to the next power of two must be in TargetLowering.h because that is where we decide whether to Widen the vector or not, and the size to which we widen it. The decision on which legalization kind to do is implemented in TargetLowering.h. The

Yes, it was I who put that rant in the commit log and it's justified. Worse, it's unreasonable to actually go through all of DAGCombiner's code and check to see if certain kinds of constants, e.g., i64, are legal during a particular phase of DAGCombiner. DAGCombiner does good work and the backends are supposed to be good citizens. CellSPU is certainly trying to be a good citizen, no

Hi Scott, I'm not clear on what you're saying here; some of your points below seem to be contradictory. The advice to use target-independent nodes when feasible seems sound to me, so I wrote up a comment about it in SelectionDAGNodes.h. If you can formulate your thoughts in the form of specific documentation changes, that would be helpful. In theory, DAGCombiner is supposed to check if

This is a bug in the implementation of WidenVecRes_Binary. On line 1546 it assumes that “Widen” is the last phase of type-legalization and we check if the result is a legal type. But actually we want to continue and promote the elements of the vector. In other cases we may want to widen (to the next power of two) and later split in half because the vector is too big. On Aug 12, 2013, at 10:46

/Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp: In function 'bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*, short int&)': /Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp:141: warning: dereferencing type-punned pointer will break strict-aliasing rules In file included from