[Patch] Enable value forwarding for loads from calloc without intervening store

Philip Reames listmail at philipreames.com
Tue Jun 10 11:07:43 PDT 2014


ping.

Duncan - it looks like another notification may have gotten lost. Did 
you see my updated changes in response to your comments?

Philip


On 05/28/2014 10:48 AM, Philip Reames wrote:
>
> On 05/28/2014 10:21 AM, Duncan P. N. Exon Smith wrote:
>> On 2014 May 28, at 09:34, Philip Reames <listmail at philipreames.com> 
>> wrote:
>>
>>> Enable value forwarding for loads from calloc without intervening store
>>> http://reviews.llvm.org/D3931
>>>
>>> This change extends GVN to handle the following case:
>>> %1 = tail call noalias i8* @calloc(i64 1, i64 4) #2
>>> %2 = bitcast i8* %1 to i32*
>>> ; This load is trivially constant zero
>>> %3 = load i32* %2, align 4
>>>
>>> This is analogous to the handling for malloc in the same places. 
>>> Malloc returns undef, calloc returns a zero value. Note that it is 
>>> correct to return zero even for out of bounds geps since the result 
>>> of such a gep would be undefined.
>>>
>>> I'm not entirely clear why this code lives in GVN rather than 
>>> elsewhere; I have chosen to simply extend the existing design.
>> I agree that this is a strange spot, so you might want to wait to hear
>> from someone else before further entrenching it.
> I would prefer to do the rearrangement as a separate change.  I'm 
> happy to contribute towards that; I just don't want to stall a useful 
> enhancement on a broader design question.  If you seriously disagree, 
> let me know.
>
> Once I've uploaded the changed diff, would you mind committing it?
>>
>> Otherwise, this LGTM with a few whitespace cleanups.
> Will fix all.  Thanks.
>>
>>> diff --git a/lib/Transforms/Scalar/GVN.cpp 
>>> b/lib/Transforms/Scalar/GVN.cpp
>>> index 6d07ddd..6250f2b 100644
>>> --- a/lib/Transforms/Scalar/GVN.cpp
>>> +++ b/lib/Transforms/Scalar/GVN.cpp
>>> @@ -1463,6 +1463,12 @@ void GVN::AnalyzeLoadAvailability(LoadInst 
>>> *LI, LoadDepVect &Deps,
>>> UndefValue::get(LI->getType())));
>>>        continue;
>>>      }
>>> +    // calloc zero initializes memory
>> Comment should probably be preceded by an empty line, and should have
>> a period.  Something like this would match the nearby comments:
>>
>>     // Loading zero-initialized allocation -> 0.
>>
>>> +    if (isCallocLikeFn(DepInst, TLI) ) {
>> This space is strange ~~~~~~~~~~~~~~~~~^
> Results from switching coding styles mid path.  I generally prefer if( 
> cond ) { .. } which is not LLVM style.  Fixed.
>>
>>> + ValuesPerBlock.push_back(AvailableValueInBlock::get(DepBB,
>>> + Constant::getNullValue(LI->getType())));
>>> +      continue;
>>> +    }
>>>
>>>      if (StoreInst *S = dyn_cast<StoreInst>(DepInst)) {
>>>        // Reject loads and stores that are to the same address but 
>>> are of
>>> @@ -1988,6 +1994,14 @@ bool GVN::processLoad(LoadInst *L) {
>>>      }
>>>    }
>>>
>>> +  // Loading from calloc returns zero
>> This comment could be improved, too.  Add a period, and match the
>> prose style of the comments nearby.
>>
>>> +  if (isCallocLikeFn(DepInst, TLI)) {
>>> + L->replaceAllUsesWith(Constant::getNullValue(L->getType()));
>>> +    markInstructionForDeletion(L);
>>> +    ++NumGVNLoad;
>>> +    return true;
>>> +  }
>>> +
>>>    return false;
>>> }
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list