[llvm-commits] [llvm] r52537 - /llvm/trunk/lib/Transforms/IPO/DeadArgumentElimination.cpp

Chris Lattner clattner at apple.com
Wed Jul 2 09:50:35 PDT 2008


On Jul 2, 2008, at 9:16 AM, Matthijs Kooijman wrote:

> Hi Chris,
>
>>> Don't let DeadArgElimination change the return type ({} into void
>>> and {T}
>>> into T) when no return values are actually dead.
>> Out of curiosity, why not?  {x} -> x would eliminate extractvalue
>> instructions, so it seems that it would reduce the size of the IR.
> I just tried a bit to implement this, but this poses problems again  
> when the
> result is used as is again. For example:
> %S = call { i32 } @foo()
> call void @bar({ i32 } %S)
>
> here the result of @foo was correctly marked live, but the code  
> would still
> try to turn it into call i32 @foo() and then be surprised that %S  
> was used by
> other stuff than extractvalues. I can solve this by, in addition to  
> a list
> of Functions that really can't be modified at all, keeping a list of  
> Functions
> whose return values really can't be modified at all (which is slightly
> different from having all return values live only for functions  
> returning a
> struct with a single element, or perhaps for zero elements as well).

I still think it would be preferable to lower this into:

%S = call i32 @foo()
%t = insertvalue {i32} undef, 0, i32 %S
call void @bar({ i32 } %t)

This is not an "optimization" by itself persay, but it *is* a  
canonicalization, and it is useful to have canonical forms for code.

> However, I'm not really sure this is worth the effort. Perhaps this  
> should be
> done in a different pass, really?

Why in a different pass?

-Chris



More information about the llvm-commits mailing list