Inefficient codegen when extracting field from temporary object

[arnetheduck]

Description

The following snippet, of critical performance importance when working with sum types, generates an inefficient copy, even though it can be seen that lifetimes are bounded in such a way that the copy can become a move:

type X = object
  s*: seq[byte]
proc f(): X = X(s: newSeq[byte](1024*1024*1024))
let v = f().s

	nimZeroMem((void*)(&T1_), sizeof(tyObject_X__4CKW0EgTl4SNofakrtBaFw));	_ZN6testit1fE((&T1_));
	genericSeqAssign((&v__testit_u35), T1_.s, (&NTIseqLbyteT__6H5Oh5UUvVCLiakt9aTwtUQ_));}

Notably, the same applies to any "last use" of a variable:

let 
  fv = f()
  v = fv.s # no need to copy if this is the last use of fv

Of course, in the real world, this applies most significantly to Option and its ilk:

proc f(): Option[seq[byte]] = ...
let
  x = f()
if x.isNone():
  return
let y = x.get() # last use of x - we can move value out of x
...

Nim Version

1.6, 2.0, devel....

Current Output

No response

Expected Output

No response

Possible Solution

No response

Additional Information

No response

[Araq]

Does it also happen with ORC?

[ringabout]

Yeah, ORC is affected too, I checked before. In moveOrCopy, nkCallKinds is supplied with genSink. Perhaps we can treat the extracting fields etc. the same way as the nkCallKinds.

[mratsim]

Probably related to performance issues I had with Option and that I tried to fix by returning lent T: #14420 (comment)

The impact of Option was 5x slowdown compared to in-place mutation + bool

[arnetheduck]

lent is unrelated / orthogonal to this issue - it should should make no difference since the contents should be moved out which lent doesn't materially affect