[llvm-commits] [llvm] r168931 - in /llvm/trunk: include/llvm/Target/TargetTransformImpl.h include/llvm/TargetTransformInfo.h lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h lib/Target/X86/X86TargetMachine.h lib/Transforms/Scalar/LoopIdiomRecognize.cpp test/Transforms/LoopIdiom/popcnt.ll

[Shuxin Yang]

Now I remember why I don't pass Type as a parameter to this function.
The pass need to examine if the underlying architecture has HW support 
(for some popular int type) at very beginning.
At that moment, it doesn't even know if the loop has popcount pattern, 
let alone which Type is involved.


>>>
>>>         Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp
>>>         URL:
>>>         http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=168931&r1=168930&r2=168931&view=diff
>>>         ==============================================================================
>>>         --- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original)
>>>         +++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Thu Nov 29
>>>         13:38:54 2012
>>>         @@ -17670,6 +17670,17 @@
>>>            return -1;
>>>          }
>>>
>>>         +ScalarTargetTransformInfo::PopcntHwSupport
>>>         +X86ScalarTargetTransformImpl::getPopcntHwSupport(unsigned
>>>         TyWidth) const {
>>>         +  assert(isPowerOf2_32(TyWidth) && "Ty width must be power
>>>         of 2");
>>>
>>>
>>>     This constraint seems strange. It certainly doesn't seem like it
>>>     should be an assert.
>>     It catch the case when this function is fed with nonsense
>>     parameter, and it at least make sense for x86
>>
>>
>> I understand, but I disagree with that design. Specifically, at the 
>> IR level we have integer types that are not powers of two width. If 
>> this is an important constraint, than it should be very clearly 
>> documented, but it would seem more reasonable in a layer like the TTI 
>> interface to either A) return 'none' or whatever the conservative 
>> answer is, or B) accept the IR-level type, run it through 
>> legalization to see the legalized type it ends up with, and use that 
>> width.
>>
>> I would suggest B here as it seems a more robust solution and to 
>> follow the spirit of TTI -- modeling the result of CodeGen when 
>> lowering the code.
> I just want to make sure the interface is very simple. If the width is 
> not power-of-2, we can simply ignore it
> for the sake of simplicity.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130109/3fb613b4/attachment.html>