[LLVMdev] should AlwaysInliner inline this case?

[Pete Cooper]

Sent from my iPhone

> On Jan 5, 2015, at 5:21 AM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> 
> On Mon, Jan 5, 2015 at 3:09 AM, David Majnemer <david.majnemer at gmail.com> wrote:
>>> 
>>> The idea of improving the inliner is also great, but you may find that it's needed for cases other than this one if i'm right about the instcombine.
>> 
>> Sadly, the combine fails because InstCombine queries CastInst::isBitCastable to determine the castable-ness of the parameter type and the argument type.  It isn't bitcastable though, it's ptrtoint/inttoptr castable.
>> 
>> The following patch opens up the optimization:
>> --- a/lib/Transforms/InstCombine/InstCombineCalls.cpp
>> +++ b/lib/Transforms/InstCombine/InstCombineCalls.cpp
>> @@ -1456,7 +1456,7 @@ bool InstCombiner::transformConstExprCastCall(CallSite CS) {
>>      Type *ParamTy = FT->getParamType(i);
>>      Type *ActTy = (*AI)->getType();
>>  
>> -    if (!CastInst::isBitCastable(ActTy, ParamTy))
>> +    if (!CastInst::isBitOrNoopPointerCastable(ActTy, ParamTy, DL))
>>        return false;   // Cannot transform this parameter value.
>>  
>>      if (AttrBuilder(CallerPAL.getParamAttributes(i + 1), i + 1).
>> @@ -1551,7 +1551,7 @@ bool InstCombiner::transformConstExprCastCall(CallSite CS) {
>>      if ((*AI)->getType() == ParamTy) {
>>        Args.push_back(*AI);
>>      } else {
>> -      Args.push_back(Builder->CreateBitCast(*AI, ParamTy));
>> +      Args.push_back(Builder->CreateBitOrPointerCast(*AI, ParamTy));
>>      }
>>  
>>      // Add any parameter attributes.
> 
> This is exactly why I added those casting utilities. With sufficient testing, this patch LGTM as a way to effectively canonicalize these cases. Need to make sure this handles all the cases of ptr->int and int->ptr with too large, too small, and just right integer sizes. If all goes well, this seems like a really nice improvement.
Nice! Can I request we add addrspacecast to the list too. It's probably in the utilities you mention but just needs a test case for this new use of the utility.

Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150105/15e87581/attachment.html>