[llvm-commits] [llvm] r159146 - in /llvm/trunk: lib/Transforms/InstCombine/InstructionCombining.cpp lib/Transforms/Scalar/SimplifyCFGPass.cpp lib/VMCore/Verifier.cpp test/Transforms/InstCombine/objsize-64.ll test/Transforms/SimplifyCFG/invoke.ll

[Chandler Carruth]

On Mon, Jun 25, 2012 at 1:42 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote:

> I only see these 3 options: allow instcombine to modify the CFG (which
> probably we don't want to, since it runs often and it's supposed to be
> cheap), don't allow instcombine to touch invoke instructions ever (and
> lose some optimization opportunities), or replace the invoke to be
> removed with an invoke to an existing no-op function/intrinsic.
> Any other idea?
>

See my other email for another idea. As a fifth option, we could add this
optimization to a different pass (SimplifyLibCalls, SimplifyCFG, whatever)
which *is* allowed to mutate the CFG. There seems no inherent reason this
must be tied to instcombine...

As a separate issue, you argue that marking the invoke as nounwind is never
correct to do, and perhaps it isn't. However, if we cannot mark the invoke
as nounwind, then I don't believe we can delete the e invoke either, as
certainly once deleted it cannot unwind. ;]

Essentially, we must decide: is it within as-if to remove an invoke to the
global operator new if the result is unused? If so, then why is it not
within as-if to mark it nounwind (not rhetorical)? Or just to remove it in
a pass other than instcombine where we are allowed to mutate the CFG?

I could see an argument that all "sane" new operators should be "elidable"
if they are unused, but if they are not elided, they must be called and
must have the opportunity to throw. But I don't think the standard provides
any such concept. Perhaps it should, but in that case we need to document
it as an extension Clang/LLVM provides. (we already have the idea of a
'sane' operator new fortunately, we can re-use that signal I suspect...)


Given these options, my preference is for some pass other than instcombine
to do this transform in the presence of an invoke, thus getting the
'elision' semantics where, if called, the operator has a chance to throw. I
would still have instcombine do the transform when a call is directly used,
and I would gate the transform on the 'sane new' bit we already have.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120625/c40755ad/attachment.html>