[IPCP] Bail on extractvalue's with more than 1 index.

[craig.topper]

Summary

The replacement code only looks at the first index of the
extractvalue. If there are additional indices we'll end
up doing a bad replacement.

This only happens if the function returns a nested struct. Not
sure if clang ever generates such code. The original report came
from ispc.

Fixes PR43857

[craig.topper]

Add test

[jdoerfert]

Besides the point: I didn't know anyone was still using this pass. Actually I was going to propose to delete it soon. Is there a desire to keep it or would people switch to IP-SCCP and/or the Attributor (assuming they subsume the functionality)? The one reason to keep this pass is that it is simple and "fast" but it's questionable if that is useful if we run either of the other ones anyway.

The patch LGTM.

[bjope]

In D69656#1728773, @jdoerfert wrote:

Besides the point: I didn't know anyone was still using this pass. Actually I was going to propose to delete it soon. Is there a desire to keep it or would people switch to IP-SCCP and/or the Attributor (assuming they subsume the functionality)? The one reason to keep this pass is that it is simple and "fast" but it's questionable if that is useful if we run either of the other ones anyway.

The patch LGTM.

I assume that I was added as reviewer due to being the last person who contributed to this pass.
It looks like the fuzzy test framework we use downstream (out-of-tree) sometimes add this pass to the opt pipeline. I blame that on historical reasons, and it is nothing that we really depend on.
So do not see my contribution earlier this year as a reason for keeping the pass around. I have no clue if the reporter of PR43857 is using this pass for something less exotic than fuzzy testing.

[craig.topper]

In D69656#1729110, @bjope wrote:

In D69656#1728773, @jdoerfert wrote:

Besides the point: I didn't know anyone was still using this pass. Actually I was going to propose to delete it soon. Is there a desire to keep it or would people switch to IP-SCCP and/or the Attributor (assuming they subsume the functionality)? The one reason to keep this pass is that it is simple and "fast" but it's questionable if that is useful if we run either of the other ones anyway.

The patch LGTM.

I assume that I was added as reviewer due to being the last person who contributed to this pass.
It looks like the fuzzy test framework we use downstream (out-of-tree) sometimes add this pass to the opt pipeline. I blame that on historical reasons, and it is nothing that we really depend on.
So do not see my contribution earlier this year as a reason for keeping the pass around. I have no clue if the reporter of PR43857 is using this pass for something less exotic than fuzzy testing.

The person who filed PR43857 sits across the aisle from me. He works on ISPC (Intel SPMD Program Compiler) which uses this pass. This may be a historical artifact in their code base where they build their own pass pipeline and they didn't know the pass had been superceded by IP-SCCP. I've pass that information along to him.

llvm/lib/Transforms/IPO/IPConstantPropagation.cpp

for (auto I = Call->user_begin(), E = Call->user_end(); I != E;) {
       Instruction *Ins = cast<Instruction>(*I);
 
       // Increment now, so we can remove the use
       ++I;
 
       // Find the index of the retval to replace with
       int index = -1;
       if (ExtractValueInst *EV = dyn_cast<ExtractValueInst>(Ins))
-        if (EV->hasIndices())
+        if (EV->getNumIndices() == 1)
           index = *EV->idx_begin();
 
       // If this use uses a specific return value, and we have a replacement,
       // replace it.
       if (index != -1) {
         Value *New = RetVals[index];
         if (New) {
           if (Argument *A = dyn_cast<Argument>(New))