[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:09 PM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Nuno,
>
> > improve optimization of invoke instructions:
> >   - simplifycfg:  invoke undef/null -> unreachable
>
> this part if OK.
>
> >   - instcombine:  invoke new  -> invoke expect(0, 0)  (an arbitrary NOOP
> intrinsic;  only done if the allocated memory is unused, of course)
>
> What is this about?  If you are saying that malloc is nounwind, why aren't
> you
> marking it nounwind in SimplifyLibCalls.
>
> In any case, by removing the restriction that you can't do invoke on an
> intrinsic you are making a major (historically speaking change).  It should
> thus be done as part of a different commit, and accompanied with a bunch of
> tests checking that codegen doesn't crash if you try to codegen code that
> does invoke of an intrinsic.
>
> Finally, doing thus funky intrinsic thing seems a bizarre approach to me,
> there has to be a better way.
>

In particular, I don't understand why we can't:

1) mark the invoke as nounwind, potentially using the same kind of logic
you use to say that it can be removed entirely
2) SimplifyCFG transform from invoke to call
3) instcombine remove the call

There are a lot of other ways to phase-order-shuffle this problem if there
is a specific pattern that needs to be simplified and is not simplified
when relying on an instcombine run after simplifycfg has run...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120625/df90617f/attachment.html>