[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