[llvm-commits] [llvm] r65758 - /llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp

[Bill Wendling]

Very possible. But there were a lot of failures. It needs  
investigation. :-)

-bw

On Mar 1, 2009, at 5:02 PM, Evan Cheng wrote:

> Even though I like to blame Chris for everything even I doubt this
> patch is at fault. It's probably exposing a bug elsewhere.
>
> Evan
>
> On Feb 28, 2009, at 7:55 PM, Bill Wendling wrote:
>
>> Author: void
>> Date: Sat Feb 28 21:55:12 2009
>> New Revision: 65758
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=65758&view=rev
>> Log:
>> Temporarily revert r65755. It was causing failures in the self- 
>> hosting
>> testsuite:
>>
>> Running /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/
>> CodeGen/X86/dg.exp ...
>> FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/
>> CodeGen/X86/nancvt.ll
>> Failed with exit(1) at line 2
>> while running: grep 2147027116 nancvt.ll.tmp | count 3
>> count: expected 3 lines and got        0.
>> child process exited abnormally
>> FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/
>> CodeGen/X86/vec_ins_extract.ll
>> Failed with exit(1) at line 1
>> while running:  llvm-as < /Volumes/Sandbox/Buildbot/llvm/full-llvm/
>> build/llvmCore/test/CodeGen/X86/vec_ins_extract.ll |  opt -
>> scalarrepl -instcombine |   llc -march=x86 -mcpu=yonah | not /usr/
>> bin/grep sub.*esp
>>     subl      $28, %esp
>>     subl      $28, %esp
>> child process exited abnormally
>>
>> And more.
>>
>> Modified:
>>   llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp
>>
>> Modified: llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp?rev=65758&r1=65757&r2=65758&view=diff
>>
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> = 
>> =====================================================================
>> --- llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp
>> (original)
>> +++ llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp Sat
>> Feb 28 21:55:12 2009
>> @@ -253,13 +253,11 @@
>>    // (allocations OF arrays are ok though), and an allocation of a
>> scalar
>>    // value cannot be decomposed at all.
>>    uint64_t AllocaSize = TD->getTypePaddedSize(AI-
>>> getAllocatedType());
>> -
>> -    // Do not promote any struct whose size is too big.
>> -    if (AllocaSize < SRThreshold)
>> -      continue;
>> -
>> +
>>    if ((isa<StructType>(AI->getAllocatedType()) ||
>>         isa<ArrayType>(AI->getAllocatedType())) &&
>> +        // Do not promote any struct whose size is too big.
>> +        AllocaSize < SRThreshold &&
>>        // Do not promote any struct into more than "32" separate
>> vars.
>>        getNumSAElements(AI->getAllocatedType()) < SRThreshold/4) {
>>      // Check that all of the users of the allocation are capable
>> of being
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits