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

[Matthijs Kooijman]

Hi Chris,

> 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)
I have no intention to make instcombine change the above into a call @bar(X)
so that should work out. However, if the front end already emits that, I don't
think we will turn it into the above.

I have been playing with a though, however, of making a multiple return
canonicalize (or rather, a first class aggregate canonicalize) that puts all
extractvalue instructions directly after their aggregate argument and
insertvalue instructions directly before their use. Also, it could prevent
aggregate return values from being used directly (ie, only through
extractvalue) and force aggregate arguments to be built just before a call
using insertvalues. Not sure what the gain from this would be yet, though, but
it might make other passes slightly simpler.

Also, I was planning on committing my flatten return value patch sometime
soon, which also makes things slightly less complicated :-)

> 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.
Yeah, I think we can thrash most uses of insert/extract quite readily, except
when dealing with multiple return values. In that specific case, it might be
useful for backends to get a canonicalized version.

> Seem reasonable?
I'll whip up something and we'll see what happens :-)

Gr.

Matthijs
-------------- 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/20080624/617d456d/attachment.sig>