Stream: t-compiler

Topic: fn-return-places


RalfJ (Oct 24 2018 at 07:49, on Zulip):

Is it true that the return place for function calls is always a local, never a compound path (with projections) or so? Would it be worth encoding that in the type? I plan to rely on that for my Stacked Borrows implementation. (The reason being a local is helpful is that it means I know the place this path evaluates to will be the same after the fn call. If the call is _local[idx] = foo(something), it might be that foo can mutate idx.)

rkruppe (Oct 24 2018 at 07:52, on Zulip):

I don't think that will be true once we stop being very dumb about return value optimizations, e.g. I think return Foo { x: a(), y: b() } should lower to something like _0.x = a(); _0.y = b(); to avoid temporaries

RalfJ (Oct 24 2018 at 09:23, on Zulip):

hm also I found a *_1 = foo()

RalfJ (Oct 24 2018 at 09:24, on Zulip):

all of these are fine though, the one thing that does not work is array indices...

rkruppe (Oct 24 2018 at 09:34, on Zulip):

Array indices will definitely show up (e.g., return [foo(), bar()] should write to _0[0] and _0[1]). variable array indices are a bit harder to imagine but could show up in combination with a move forwarding optimization, consider fn foo() -> [i32; 500] { let mut a = [0; 500]; for i in 0..500 { a[i] = f(i); } a } and suppose we eliminate the copy from a into the return place

RalfJ (Oct 24 2018 at 09:49, on Zulip):

I'll just not retag behind array indices for now

RalfJ (Oct 24 2018 at 09:50, on Zulip):

which means the compiler wouldnt be allowed to track aliasing of references stored in arrays as precisely as it does for locals that are directly of ref type

RalfJ (Oct 24 2018 at 09:50, on Zulip):

not perfect, but a start I guess...

Last update: Nov 16 2019 at 02:00UTC