search for: sext_in_reg

...be permissible to add a virtual function to TargetLowering such that the target can effectively say, "Really, the setcc is legal, no need to truncate!"? The alternative is to do fairly deep inspection of brconds to eliminate the truncate, which eventually gets expanded into: (i8:sext_in_reg (i8:truncate (i32:setcc ...))) -scooter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081212/397249df/attachment.html>

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 (setcc ...)) patterns easily because the truncate is being custom lowered.

On Fri, Dec 12, 2008 at 11:42 AM, Scott Michel <scottm at aero.org> wrote: > The alternative is to do fairly deep inspection of brconds to eliminate the > truncate, which eventually gets expanded into: > (i8:sext_in_reg (i8:truncate (i32:setcc ...))) Have you tried implementing computeMaskedBitsForTargetNode for your setcc nodes? If you have, I think DAGCombiner should take care of the necessary simplification. -Eli

if (N0.getOpcode() == ISD::SETCC && (LegalOperations || (!LegalOperations && VT.isPow2VectorType()))) But the comment right after it is: // sext(setcc) -> sext_in_reg(vsetcc) for vectors. // Only do this before legalize for now. if (VT.isVector() && !LegalOperations) { So, these optimizations are never safe in the general case if we can't guarantee that TLI.getSetCCResultType() returns a valid type. From: Rotem, Nadav [mailto:nadav.rotem at...

...Rotem, Nadav; Developers Mailing List Subject: RE: TLI.getSetCCResultType() and/or MVT broken by design? if (N0.getOpcode() == ISD::SETCC && (LegalOperations || (!LegalOperations && VT.isPow2VectorType()))) But the comment right after it is: // sext(setcc) -> sext_in_reg(vsetcc) for vectors. // Only do this before legalize for now. if (VT.isVector() && !LegalOperations) { So, these optimizations are never safe in the general case if we can't guarantee that TLI.getSetCCResultType() returns a valid type. From: Rotem, Nadav [mailto:nadav.rotem at...

My target has only logical shifts and lacks an arithmetic right shift instruction. I have a custom LowerSRA function that rewrites SRA as SHL + SIGN_EXTEND when the shift width is either constant 16 or 24. Unfortunately, I observe that a later pass combines the SHL + SIGN_EXTEND back into SRA so we crash. The idea I had for defeating this behavior is lower to a target-specific version of SHL

Hi Micah, I think that getSetCCResultType should only be called for legal types. Disabling it on isPow2VectorType is not the way to go because there are other illegal vector types which are pow-of-two. I suggest that you call it only after type-legalization. BTW, you can't set the LLVMTy yourself because you don't have access to the LLVMContext at that point. Nadav From:

I'm running into lots of problems with this call back. Mostly the problem occurs because this callback is used before types are legalized. However, the code generator does not have a 1-1 correspondence between all LLVM types and the codegen types. This leads to problems when getSetCCResultType is passed in an invalid type, but has a valid LLVM type attached to it. An example is <3 x