[llvm-commits] [llvm] r90108 - in /llvm/trunk: include/llvm/CodeGen/SelectionDAG.h lib/CodeGen/SelectionDAG/LegalizeTypes.cpp lib/CodeGen/SelectionDAG/LegalizeTypes.h lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp lib/CodeGen/SelectionDAG/SelectionDAG.cpp lib/Target/X86/X86ISelLowering.cpp

Mon Ping Wang wangmp at apple.com
Mon Nov 30 13:17:56 PST 2009


Hi Duncan,

On X86, dividing by zero will generate an exception.  Since on X86, we would unroll any vector division to scalars elements and rebuild the vector, it seemed cleaner to me that we custom widen by doing the scalar division on the elements on the original vector, and widen the result with undefs.  I agree with you for architectures whose divide traps on zero but has a vector division, it would probably be more efficient for widening to copy the last element (or place 1s)  across the vector. For architectures that do not trap on division, the normal widening code would handle it correctly.

-- Mon Ping


On Nov 30, 2009, at 4:33 AM, Duncan Sands wrote:

> Hi Mon Ping,
> 
>> Added support to allow clients to custom widen. For X86, custom widen vectors for
>> divide/remainder since these operations can trap by unroll them and adding undefs
>> for the resulting vector.
> 
> does this really have anything to do with unrolling?  After all, even if you
> don't unroll then the additional vector elements might contain anything (since
> they are "undef") and "anything" might be zero if you get unlucky.  Will that
> trap with vector division (or does it slow the division down?)  Wouldn't it
> be better to ensure that the extra elements in the denominator of the division
> contain 1 or some other thing sure to be non-zero.
> 
> Ciao,
> 
> Duncan.





More information about the llvm-commits mailing list