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

[Dale Johannesen]

On Jul 2, 2008, at 9:50 AMPDT, Chris Lattner wrote:
> 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.

Maybe I'm missing something, but wouldn't this assume call i32 and
call {i32} use the same calling convention?  I don't think we can assume
that in general.

>>> 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
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits