Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicit Tail Calls #3407

Open
wants to merge 92 commits into
base: master
Choose a base branch
from
+840 −0
Open

Explicit Tail Calls #3407

Changes from 1 commit
Commits
Show all changes
92 commits
Select commit Hold shift + click to select a range
68572cc
[WIP] start writing an initial draft
Apr 1, 2023
59345b2
[WIP] keep writing on RFC
Apr 2, 2023
6d24e88
add some more TODOs
Apr 2, 2023
72209f8
rationale and alternatives
Apr 3, 2023
4beeedd
finish up rationale and alternatives
Apr 3, 2023
60c0242
fix some formatting issues
Apr 3, 2023
7fecbad
prior art add links
Apr 4, 2023
ff899fd
finish up prior-art
Apr 5, 2023
98dfe99
add reference-level explanation
Apr 5, 2023
6233cc3
add unresolved questions and future possibilities
Apr 5, 2023
dde8305
final pass
Apr 6, 2023
03bdd9f
update based on reviews
phi-go Apr 6, 2023
30967a7
remove stray TODO
phi-go Apr 7, 2023
53a15cc
add TailCall MIR node
phi-go Apr 7, 2023
ce069c4
update implementation
phi-go Apr 7, 2023
ae2f3b8
gcc supports require tail call
phi-go Apr 7, 2023
377268e
indirect and external functions are supported
phi-go Apr 7, 2023
046b5e4
whitespace changes
phi-go Apr 7, 2023
f8da276
fix grammar
phi-go Apr 7, 2023
0d3589a
fix typo
phi-go Apr 7, 2023
0d1c3bd
make section on difference between return and become clearer
phi-go Apr 7, 2023
6f313d6
update use case 1 description
phi-go Apr 7, 2023
9482ad2
reword impact
phi-go Apr 7, 2023
3e7c384
improve wording of type checking section
phi-go Apr 7, 2023
46d8db3
update example illustrating the difference between return and become
phi-go Apr 9, 2023
12b028c
update comments on use case examples
phi-go Apr 9, 2023
b0c869e
correct grammar mistake
phi-go Apr 9, 2023
fd35d0f
change example in semantics section to ref
phi-go Apr 9, 2023
bef3933
rewrite to use TCE
Apr 11, 2023
e03c869
change feature name
phi-go Apr 17, 2023
86ad37b
use the term TCE correctly
phi-go Apr 17, 2023
c55c189
add more unresolved questions
phi-go Apr 17, 2023
77f93ac
update attribute on return section
phi-go Apr 17, 2023
417aa48
fix wrong link
phi-go Apr 18, 2023
9a24c19
add another reference to question regarding lints
phi-go Apr 18, 2023
f23c09e
expand on why operators are not supported
phi-go Apr 19, 2023
8ab2fbd
simplify reference-level explanation
phi-go Apr 20, 2023
0df947b
do another writing pass
phi-go Apr 20, 2023
0abc63a
passing borrows of local variables is not allowed
phi-go Apr 20, 2023
b263a9d
add example for arguments that are calls
phi-go Apr 22, 2023
70c0748
fix typo in example
phi-go Apr 22, 2023
d17ba51
reword sentence
phi-go Apr 22, 2023
0b47449
merge borrow checking and difference sections
phi-go Apr 22, 2023
1b4b6c2
do a grammar pass
phi-go Apr 22, 2023
578b33f
improve accuracy of steps done by become
phi-go Apr 22, 2023
dae7085
fix mistake in drop order example
phi-go Apr 22, 2023
acef709
be more clear on where become can be used
phi-go Apr 24, 2023
e8df199
update description comparing return and become
phi-go Apr 24, 2023
4dc10e8
add return become alternative
phi-go Apr 24, 2023
3c20119
add alternative: explicit dropping of variables
phi-go May 3, 2023
f46aa13
fix date formatting
phi-go May 5, 2023
b6b3094
update with discussion on WebAssembly
phi-go May 6, 2023
94916aa
update summary and motivation
phi-go May 12, 2023
ae758f5
update tail call elimination section
phi-go May 12, 2023
2824fc9
use slice instead of list example
phi-go May 12, 2023
da261a4
update wording for use case 1
phi-go May 12, 2023
5c2485e
update alternating example description
phi-go May 12, 2023
0e4a645
add impl effort for explicit drop alternative
phi-go May 12, 2023
eeaa80c
resolving unresolved questions
phi-go May 12, 2023
18ec62d
add resolved questions section
phi-go May 13, 2023
36d4734
expand reference-level explanation
phi-go May 15, 2023
7354862
remove unneeded comment
phi-go May 15, 2023
c647332
add type comment to example
phi-go May 15, 2023
e7bc960
update description of return type coercion
phi-go May 15, 2023
c5301f2
add pointer coercions
phi-go May 15, 2023
12c495b
mismatches in mutability
phi-go May 16, 2023
4b18487
update generators
phi-go May 16, 2023
b3dc340
update async
phi-go May 16, 2023
3010c2e
add future possibilities to relax requirements
phi-go May 17, 2023
60a290b
remove async as open question
phi-go May 17, 2023
72f8e4a
remove open question on functions that abort
phi-go May 17, 2023
980ebeb
fix typos
phi-go May 17, 2023
51ecc12
update zig example
phi-go May 17, 2023
dfcf7e8
extend rationale and alternatives section
phi-go May 21, 2023
f7652a9
update async description
phi-go May 23, 2023
0533221
update async description
phi-go May 23, 2023
8706d7b
fix typo
phi-go May 23, 2023
0b61f07
update reference-level explanation
phi-go May 23, 2023
b7c69e4
move mutability mismatch to future
phi-go May 23, 2023
23106d2
add fn tokens
phi-go May 23, 2023
2946d63
performance guarantee
phi-go May 24, 2023
cdac5c2
lint unresolved question to future possibilites
phi-go May 24, 2023
c7e4ea7
expand motivation section
phi-go May 25, 2023
b4b3db4
update wasm3 description
phi-go May 25, 2023
e548a96
Update wasm3 link
phi-go May 25, 2023
d38ba99
update motivation examples
phi-go May 26, 2023
d406786
Add RFC PR link and tracking issue link
phi-go Sep 28, 2024
095fc54
Update text/0000-explicit-tail-calls.md
phi-go Nov 5, 2024
8fafb63
Update text/0000-explicit-tail-calls.md
phi-go Nov 5, 2024
e4ccaa3
Add section on successors/combinators and improve local goto section
phi-go Nov 10, 2024
5e34a7e
Update text/0000-explicit-tail-calls.md
phi-go Nov 11, 2024
50bf9c1
Update text/0000-explicit-tail-calls.md
phi-go Nov 11, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 8 additions & 1 deletion text/0000-explicit-tail-calls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -505,6 +505,13 @@ Tail calls can be implemented without backend support if only static calls are s

There are some designs that either can not achieve the same performance or functionality as the chosen approach. Though most other designs evolve around how to mark what should be a tail-call or marking what functions can be tail called. There is also the possibility of providing support for a custom backend (e.g. LLVM) or MIR pass.

### Rust Built-in Functionality

For simple tail recursion on an iterable (successors)[https://doc.rust-lang.org/stable/core/iter/fn.successors.html] can be used to compute a result for each element.
phi-go marked this conversation as resolved.
Show resolved Hide resolved
Nearly equivalently, a (combinator)[https://users.rust-lang.org/t/when-will-rust-have-tco-tce/20790/3] can be used to express a tail recursive function, however, allowing more flexibility regarding the returned result.

These approaches do not provide a way to express general tail calls, so do not fulfill a basic requirement we would like to achieve.

### Trampoline based Approach
There could be a trampoline-based approach
([comment](https://github.com/rust-lang/rfcs/pull/1888#issuecomment-326952763)) that can fulfill the semantic guarantee
Expand All @@ -515,7 +522,7 @@ Similarly, as mentioned [here](https://github.com/rust-lang/rfcs/pull/3407#discu

### Principled Local Goto
One alternative would be to support some kind of local goto natively, indeed there exists a
[pre-RFC](https://internals.rust-lang.org/t/pre-rfc-safe-goto-with-value/14470/9?u=scottmcm) ([comment](https://github.com/rust-lang/rfcs/issues/2691#issuecomment-1458604986)). This design should be able to achieve the same performance and stack usage, though it seems to be quite difficult to implement and does not seem to be as flexible as the chosen design, especially regarding indirect calls and external functions.
[pre-RFC](https://internals.rust-lang.org/t/pre-rfc-safe-goto-with-value/14470/9?u=scottmcm) ([comment](https://github.com/rust-lang/rfcs/issues/2691#issuecomment-1458604986)) or another (LLVM specific idea)[https://internals.rust-lang.org/t/idea-for-safe-computed-goto-using-enums/21787?u=programmerjake]. These designs should be able to achieve the targeted performance and stack usage, though they seems to be quite difficult to implement or are backend specific. Also they do not seem to be as flexible as the chosen design, especially implementing tail calls to indirect or external functions do not seem to be feasible.
phi-go marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the computed goto idea I proposed isn't LLVM specific, since computed goto originally was a gcc extension for C/C++ before LLVM started, so it should work just fine in gcc too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo computed goto is more useful than tail calls in some situations (e.g. better register allocation due to not being restricted by the function call ABI) and less useful in others, so I think both tail calls and computed goto are worth adding to rust.

Copy link

@rpjohnst rpjohnst Nov 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle there's nothing preventing an optimizer from doing the same sort register allocation with tail calls, if the callees are equivalently local to the goto targets.

And on the other hand, in practice tail calls using a fixed ABI can produce better register allocation than computed goto, because a big irreducible CFG can trip up the allocator's heuristics in ways that separate functions can be written to avoid.

The better argument for computed goto is to unlock intraprocedural borrow checking, but even then it should probably look more like a tail call to a local function (with parameters), analogous to break-with-value, and less like the C extension, which doesn't play well with block scope or destructors.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the following Lisp-inspired syntax?

tagbody! {
   'a: {  /* do some work */ goto 'b; }
   'b: { /* do some work */ 1 }
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the following Lisp-inspired syntax?

tagbody! {
   'a: {  /* do some work */ goto 'b; }
   'b: { /* do some work */ 1 }
}

the syntax I had proposed is essentially equivalent to that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@programmerjake Would you agree that local gotos require backend support? Then I would update that section to mention that instead.

I would also add some text that local gotos could have other applications than for tail calls. While this seems to already be disputed I guess we do not really know until this is tried?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@programmerjake Would you agree that local gotos require backend support?

yes, assuming you meant computed goto (jumping to an address in a variable instead of to a known label), but afaik all targets on gcc and/or llvm already support computed goto -- the main issue i raised in that internals thread is LLVM doesn't have a way to refer to a label's address from another codegen unit, so that needs to be fixed or worked around if we're using enums and not just a raw pointer to hold the addresses of our labels.

Then I would update that section to mention that instead.

ok

I would also add some text that local gotos could have other applications than for tail calls.

computed gotos do not let you make tail calls, they only work within a function instead of calling between functions. they can just be used for similar applications such as making fast interpreters.

gotos in general are also useful for expressing irreducible control flow, if we got computed goto, it can also be used as a normal goto to express that control flow.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, assuming you meant computed goto (jumping to an address in a variable instead of to a known label), but afaik all targets on gcc and/or llvm already support computed goto -- the main issue i raised in that internals thread is LLVM doesn't have a way to refer to a label's address from another codegen unit, so that needs to be fixed or worked around if we're using enums and not just a raw pointer to hold the addresses of our labels.

Ah, thanks for the clarification. So for a known label this is in theory possible without backend support?

computed gotos do not let you make tail calls, they only work within a function instead of calling between functions. they can just be used for similar applications such as making fast interpreters.

Yeah, sorry I meant other use cases than being a possible alternative to the functionality provided by tail calls.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, thanks for the clarification. So for a known label this is in theory possible without backend support?

Yes, MIR is a CFG already. Jumping to a known label uses the exact same MIR block terminator as is used for eg control flow converging back to the same code path after an if else. Only the MIR building code and steps before it would need to be updated.


### Attribute on Function Declaration
[attribute-on-function-declaration]: #attribute-on-function-declaration
Expand Down