2017-08-02 08:28:10 +08:00
|
|
|
; RUN: llc -mtriple=i686-- -o - < %s | FileCheck %s
|
Refactor isInTailCallPosition handling
This change came about primarily because of two issues in the existing code.
Niether of:
define i64 @test1(i64 %val) {
%in = trunc i64 %val to i32
tail call i32 @ret32(i32 returned %in)
ret i64 %val
}
define i64 @test2(i64 %val) {
tail call i32 @ret32(i32 returned undef)
ret i32 42
}
should be tail calls, and the function sameNoopInput is responsible. The main
problem is that it is completely symmetric in the "tail call" and "ret" value,
but in reality different things are allowed on each side.
For these cases:
1. Any truncation should lead to a larger value being generated by "tail call"
than needed by "ret".
2. Undef should only be allowed as a source for ret, not as a result of the
call.
Along the way I noticed that a mismatch between what this function treats as a
valid truncation and what the backends see can lead to invalid calls as well
(see x86-32 test case).
This patch refactors the code so that instead of being based primarily on
values which it recurses into when necessary, it starts by inspecting the type
and considers each fundamental slot that the backend will see in turn. For
example, given a pathological function that returned {{}, {{}, i32, {}}, i32}
we would consider each "real" i32 in turn, and ask if it passes through
unchanged. This is much closer to what the backend sees as a result of
ComputeValueVTs.
Aside from the bug fixes, this eliminates the recursion that's going on and, I
believe, makes the bulk of the code significantly easier to understand. The
trade-off is the nasty iterators needed to find the real types inside a
returned value.
llvm-svn: 187787
2013-08-06 17:12:35 +08:00
|
|
|
|
|
|
|
|
; This used to be classified as a tail call because of a mismatch in the
|
|
|
|
|
; arguments seen by Analysis.cpp and ISelLowering. As seen by ISelLowering, they
|
|
|
|
|
; both return {i32, i32, i32} (since i64 is illegal) which is fine for a tail
|
|
|
|
|
; call.
|
|
|
|
|
|
|
|
|
|
; As seen by Analysis.cpp: i64 -> i32 is a valid trunc, second i32 passes
|
|
|
|
|
; straight through and the third is undef, also OK for a tail call.
|
|
|
|
|
|
|
|
|
|
; Analysis.cpp was wrong.
|
|
|
|
|
|
|
|
|
|
; FIXME: in principle we *could* support some tail calls involving truncations
|
|
|
|
|
; of illegal types: a single "trunc i64 %whatever to i32" is probably valid
|
|
|
|
|
; because of how the extra registers are laid out.
|
|
|
|
|
|
|
|
|
|
declare {i64, i32} @test()
|
|
|
|
|
|
|
|
|
|
define {i32, i32, i32} @test_pair_notail(i64 %in) {
|
|
|
|
|
; CHECK-LABEL: test_pair_notail
|
|
|
|
|
; CHECK-NOT: jmp
|
|
|
|
|
|
|
|
|
|
%whole = tail call {i64, i32} @test()
|
|
|
|
|
%first = extractvalue {i64, i32} %whole, 0
|
|
|
|
|
%first.trunc = trunc i64 %first to i32
|
|
|
|
|
|
|
|
|
|
%second = extractvalue {i64, i32} %whole, 1
|
|
|
|
|
|
|
|
|
|
%tmp = insertvalue {i32, i32, i32} undef, i32 %first.trunc, 0
|
|
|
|
|
%res = insertvalue {i32, i32, i32} %tmp, i32 %second, 1
|
|
|
|
|
ret {i32, i32, i32} %res
|
|
|
|
|
}
|