[llvm-commits] [llvm] r159876 - in /llvm/trunk: lib/Transforms/InstCombine/InstructionCombining.cpp test/Transforms/InstCombine/badmalloc.ll test/Transforms/InstCombine/invoke.ll test/Transforms/InstCombine/malloc-free-delete.ll test/Transforms/InstCombine/objsize-64.ll test/Transforms/InstCombine/objsize.ll

[Nick Lewycky]

Duncan Sands wrote:
> Hi Nuno,
>
>> --- llvm/trunk/lib/Transforms/InstCombine/InstructionCombining.cpp (original)
>> +++ llvm/trunk/lib/Transforms/InstCombine/InstructionCombining.cpp Fri Jul  6 18:09:25 2012
>> @@ -1137,12 +1137,29 @@
>>          }
>>        }
>>        if (IntrinsicInst *II = dyn_cast<IntrinsicInst>(U)) {
>> -      if (II->getIntrinsicID() == Intrinsic::lifetime_start ||
>> -          II->getIntrinsicID() == Intrinsic::lifetime_end) {
>> +      switch (II->getIntrinsicID()) {
>> +      default: return false;
>> +      case Intrinsic::memmove:
>> +      case Intrinsic::memcpy:
>> +      case Intrinsic::memset: {
>> +        MemIntrinsic *MI = cast<MemIntrinsic>(II);
>> +        if (MI->isVolatile() || MI->getRawDest() != V)
>
> why exclude volatile stores?  If all that is being done to the allocated memory
> is doing a bunch of volatile stores to it, I don't see why you can't discard
> them and the allocation too.

Please don't do that. While that would not miscompile C or C++, LLVM has 
a stronger sense of the term volatile:

   "The optimizers must not change the number of volatile operations or 
change their order of execution relative to other volatile operations. 
The optimizers may change the order of volatile operations relative to 
non-volatile operations." -- http://llvm.org/docs/LangRef.html#volatile

In reality, people non-standardly use volatile pointers in C/C++ to tell 
the compiler to not optimize something, and LLVM politely supports this.

Nick

PS. I might be guilty of using a volatile pointer to malloc'd memory 
that has no other users, just to keep the malloc call around. Might be.