[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
nicholas at mxc.ca
Mon Jul 9 01:06:17 PDT 2012
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.
More information about the llvm-commits
mailing list