[llvm-commits] [PATCH] extend analysis passes to treat malloc calls the same as MallocInst (patch #2)

[Victor Hernandez]

On Sep 18, 2009, at 8:55 AM, Victor Hernandez wrote:

>>
>> Index: lib/Analysis/ValueTracking.cpp
>> ===================================================================
>> --- lib/Analysis/ValueTracking.cpp	(revision 81898)
>> +++ lib/Analysis/ValueTracking.cpp	(working copy)
>> @@ -20,6 +20,7 @@
>> #include "llvm/IntrinsicInst.h"
>> #include "llvm/LLVMContext.h"
>> #include "llvm/Operator.h"
>> +#include "llvm/Analysis/MallocHelper.h"
>> #include "llvm/Target/TargetData.h"
>> #include "llvm/Support/GetElementPtrTypeIterator.h"
>> #include "llvm/Support/MathExtras.h"
>> @@ -621,6 +622,24 @@
>>         break;
>>       }1
>>       }
>> +    } else if (CallInst* CI = extractMallocCall(I)) {
>> +      unsigned Align = 0;
>> +      const Type* T = getMallocAllocatedType(CI);
>> +      if (TD && T) {
>> +        // Malloc returns maximally aligned memory.
>> +        Align = TD->getABITypeAlignment(T);
>> +        Align =
>> +          std::max(Align,
>> +                   (unsigned)TD->getABITypeAlignment(
>> +                     Type::getDoubleTy(V->getContext())));
>> +        Align =
>> +          std::max(Align,
>> +                   (unsigned)TD->getABITypeAlignment(
>> +                      Type::getInt64Ty(V->getContext())));
>> +      }
>> +      if (Align > 0)
>> +        KnownZero = Mask & APInt::getLowBitsSet(BitWidth,
>> +                                                 
>> CountTrailingZeros_32(Align));
>>     }
>>     break;
>>   }
>>
>> This is simply wrong; we can't make that guarantee for malloc.
>> Consider, for example, a malloc used as an SSE vector on Windows.
>
> I agree that this is wrong; yet the bug you describe currently  
> exists in LLVM TOT and results in better codegen on some systems.   
> RaiseAllocations creates a MallocInst with no specified alignment.   
> KnownZero for MallocInst ends up getting the wrong alignment, just  
> like malloc calls would with this code.
>
> I am not sure what to do in this scenario.  I agree that getting rid  
> of this code is correct for the example you mention, but the code is  
> currently resulting in aligned instructions being generated on  
> MacOSX/x86, so it's tempting to keep it in.
>

After discussing this further, I am not going to persist the current  
malloc alignment bug.  I'll won't commit this patch, and file a bug to  
extend TargetData to identify the target-specific malloc alignment.

Victor


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