[llvm-commits] [llvm] r52217 - in /llvm/trunk: lib/Transforms/Scalar/InstructionCombining.cpp test/Transforms/InstCombine/extractvalue.ll

[Chris Lattner]

On Jun 24, 2008, at 1:33 AM, Matthijs Kooijman wrote:
>> visitExtractValueInst(I) {
>>   op = I.getOperand(0);
>>   if (isa<ConstantAggZero>(op))
>>     use new zero;
>>   else if (insertvalueinst) {
>>     if (index is the thing inserted)
>>       use inserted value
>>     else
>>       use new extract value inst of aggregate input
>> ...
>> }
>
> The inserted extractvalues can be folded in the next iteration,  
> resulting in
> the wanted:
>
> 	D = insertvalue undef, X, 0 ; {X, _}
> 	C = insertvalue A, Y, 1 ; {X, Y}
>
> So, it seems that this approach is indeed simpler and would work in  
> all cases
> I can think of just now. Any other thoughts?

I think it will work.  To me, the most interesting cases is when  
things get scalarized.  I really wouldn't mind seeing things like:


X = call {a,b,c} @foo()

%a = extract X, 0
%b = extract X, 1
%c = extract X, 2


%A = insert undef, %a, 0
%B = insert %A, %b, 1
%C = insert %B, %c, 2
call void @bar(%C)


As Dan likes to say, first class aggregate should really be treated as  
a convenience to front-end authors.  I think the optimizer should rip  
them apart readily as soon as possible as much as possible.  Having  
instcombine do this is a great thing for local aggregate accesses, and  
having IP passes do this for argument/results when the ABI can be  
changed is also great.

Seem reasonable?

-Chris