search for: computenumsignbits

ComputeNumSignBits() is never called. Moreover, Cell SPU has to custom lower truncates in a specific way to preserve register uniformity (scalar and vector representation is one and the same, or, put another way, the scalar and vector registers are the same register.) Consequently, I can't trap (truncate...

Hi Eli, > Have you tried implementing computeMaskedBitsForTargetNode for your > setcc nodes? If you have, I think DAGCombiner should take care of the > necessary simplification. he doesn't need to: the DAG combiner knows all about SetCC values, and should simplify this already. Ciao, Duncan.

...tsForTargetNode for your >> setcc nodes? If you have, I think DAGCombiner should take care of the >> necessary simplification. > > he doesn't need to: the DAG combiner knows all about SetCC values, > and should simplify this already. Oh, this is ISD::SETCC? SelectionDAG::ComputeNumSignBits doesn't currently know how to handle it, but that should be easy to fix. -Eli

...i specifies that the result comes back in an i32 register, then this means that the top 25 bits are known to match. Capturing this information in the IR is important, because it otherwise unsafe to assume that this is the case. The optimizer and code generator has logic (see SelectionDAG::ComputeNumSignBits) that propagates around the number of sign bits that a computation is known to have. This allows it to eliminate redundant sign extension instructions, and this is very important for common RISCy systems. Since the C ABI guarantees that "X" returns a sign extended value here, it...

Thanks again for your help Steve, I’m thinking perhaps my “SelectADDRrr” pattern is inadequate. The sign-extension is at the hardware level, the code generator sees (should see) it as a 16-bit signed register value. My implementation is just: bool SHAVEISelDAGtoDAG::SelectADDRrr(SDValue &Addr, SDValue &Base, SDValue &Offset) { if ((Addr.getOpcode() == ISD::ADD) { Base

>Ok, I'm not sure what issue you mean. Can you restate? I'm referring to your statement (below) where you say "there needs to be some attribute (or something) on foo". What I don't understand is I don't know who would be setting this attribute? Whatever you do, if you consider caller and callee are in different translation units, then all that we can know in the

On Mon, 19 May 2008 Alireza.Moshtaghi at microchip.com wrote: > Correction: > > The analysis I made regarding the callers knowledge of sign/zero > extension of return value is flawed. So I take it back. > > Never the less, I don't see how adding attributes would resolve this > problem either. Ok, I'm not sure what issue you mean. Can you restate? -Chris >

...gt; result comes back in an i32 register, then this means that the top 25 > bits are known to match. Capturing this information in the IR is > important, because it otherwise unsafe to assume that this is the case. > > The optimizer and code generator has logic (see > SelectionDAG::ComputeNumSignBits) that propagates around the number of > sign bits that a computation is known to have. This allows it to > eliminate redundant sign extension instructions, and this is very > important for common RISCy systems. > > Since the C ABI guarantees that "X" returns a sign extend...

...amp;, llvm::APInt&, llvm::TargetData const*, unsigned int)in libLLVMAnalysis.a(ValueTracking.cpp.o) llvm::ComputeMaskedBits(llvm::Value*, llvm::APInt const&, llvm::APInt&, llvm::APInt&, llvm::TargetData const*, unsigned int)in libLLVMAnalysis.a(ValueTracking.cpp.o) llvm::ComputeNumSignBits(llvm::Value*, llvm::TargetData const*, unsigned int)in libLLVMAnalysis.a(ValueTracking.cpp.o) llvm::TargetData::getTypeStoreSize(llvm::Type const*) constin libLLVMAnalysis.a(ValueTracking.cpp.o) llvm::TargetData::getTypeStoreSize(llvm::Type const*) constin libLLVMSelectionDAG.a(Legalize...

...amp;, llvm::APInt&, llvm::TargetData const*, unsigned int)in libLLVMAnalysis.a(ValueTracking.cpp.o) llvm::ComputeMaskedBits(llvm::Value*, llvm::APInt const&, llvm::APInt&, llvm::APInt&, llvm::TargetData const*, unsigned int)in libLLVMAnalysis.a(ValueTracking.cpp.o) llvm::ComputeNumSignBits(llvm::Value*, llvm::TargetData const*, unsigned int)in libLLVMAnalysis.a(ValueTracking.cpp.o) llvm::TargetData::getTypeStoreSize(llvm::Type const*) constin libLLVMAnalysis.a(ValueTracking.cpp.o) llvm::TargetData::getTypeStoreSize(llvm::Type const*) constin libLLVMSelectionDAG.a(Legalize...

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

...asUMUL_LOHI || HasSMUL_LOHI) { - SDValue LL, LH, RL, RH; - ExpandOp(Node->getOperand(0), LL, LH); - ExpandOp(Node->getOperand(1), RL, RH); - unsigned OuterBitSize = Op.getValueSizeInBits(); - unsigned InnerBitSize = RH.getValueSizeInBits(); - unsigned LHSSB = DAG.ComputeNumSignBits(Op.getOperand(0)); - unsigned RHSSB = DAG.ComputeNumSignBits(Op.getOperand(1)); - APInt HighMask = APInt::getHighBitsSet(OuterBitSize, InnerBitSize); - if (DAG.MaskedValueIsZero(Node->getOperand(0), HighMask) && - DAG.MaskedValueIsZero(Node->getOperand(1), High...