[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

[Duncan Sands]

Hi Nuno,

>> This sounds like it could be independently useful, but one of the ideas of
>> llvm.undef.result is that it wouldn't have to have the same argument and
>> result types.  In the case of instcombine wanting to zap an arbitrary invoke,
>> it would be nice for it to be able to just create a new intrinsic (with the
>> right type) and replace the callee of the invoke, rather than removing the
>> invoke and replacing it with another one.
>>
>> That said, now that I think about it, I don't know how interesting or
>> practical this is.  The getIntrinsic() call wants the list of parametric types
>> for the intrinsic.  Having to extract all those out of the invoke to pass into
>> getIntrinsic() is probably more work than it is to just replace the invoke call.
>
> That's a very important point. I was trying to implement this intrinsic, but
> it's quite difficult. Right now it's not possible to declare a parameter of an
> intrinsic as having an arbitrary type, nor tablegen supports variadics.
> Is all this work useful, or can I just get away with a simpler version?

I don't think the type matters for you.  You can do RAUW on the original
invoke result, replacing it with undef.  Then, replace the invokee with an
intrinsic with an arbitrary result type (even void type).

Ciao, Duncan.

>
> Nuno
>
> P.S.: Regarding the llvm.identity thing, it's not forgotten; I just didn't spend
> enough brain cycles to think about those undef issues yet.