[llvm-commits] [llvm] r52677 - in /llvm/trunk: lib/Transforms/IPO/DeadArgumentElimination.cpp test/Transforms/DeadArgElim/2008-06-23-DeadAfterLive.ll test/Transforms/DeadArgElim/deadretval2.ll test/Transforms/DeadArgElim/multdeadretval.ll

Matthijs Kooijman matthijs at stdin.nl
Wed Jul 2 01:40:01 PDT 2008


Hi Evan (and others),

> This is breaking SPEC/CFP2006/447.dealII. (Note cbe has never worked  
> because this test uses exception handling).  Do you have access to  
> SPEC 2006?
Thanks to the help of you and Owen I tracked this down to a specific use of
invoke instructions. The pass was wrongly performing the use -> argument
number translation by taking the operand number - 1.

The attached patch fixes this by doing the followin InvokeInst special
casin:

+        unsigned ArgNo = U.getOperandNo() - 1;
+        if (isa<InvokeInst>(CS.getInstruction()))
+          // Skip the to and unwind operands
+          // TODO: Let CallSite do this magic
+          ArgNo -= 2;

This is obviously ugly and this should be abstracted into CallSite. CallSite
already abstracts the argument number -> operand translation with its
getArgument() method.

I'm not completely sure how to do the reverse. I think the best approach is to
add a getArgumentNo() method that takes an operand number and returns the
number of the corresponding argument. Alternatively, it could take a use
iterator, Value* or Use* or something like that, but I think that will mostly
lead to inefficient code.

Any thoughts?

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: deadarg.diff
Type: text/x-diff
Size: 47676 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20080702/791d1d83/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20080702/791d1d83/attachment.sig>


More information about the llvm-commits mailing list