Create analogue to LoadNativeField for non-Object fields

[sstrickl]

Currently, we can load <X>Ptr-typed fields in raw (e.g.,<Y>Layout) objects by using LoadNativeField. However, no analogue exists for fields that are not boxed types (e.g., uint32_t-typed fields).

This came up while working on #40813, where I needed to be able to inspect the number of fixed and optional parameters for a closure function where the closure function is not known statically, which requires extracting the value of the packed_fields_ field, which is of type uint32_t.

As a short-term workaround, I have added the right entries into the helper methods used by the LoadIndexed instruction to make the contents of a FunctionLayout object addressable as if the non-tagged portion was an external uint32_t array. A better solution for the long term would be to introduce another instruction (LoadUnboxedNativeField?) with appropriate Slot-like machinery for defining extractable unboxed fields from raw objects, and then remove the kFunctionCid hack in the various places it appears.

[alexmarkov]

@dcharkes We could also use such low-level load/store instructions in FFI implementation (e.g. in FlowGraphBuilder::UnwrapHandle()).

[sstrickl]

I've already got on a start on this on CL 155604, at least for the case I currently need (uint32_t), and it should be easily extendable to other unboxed field types. In that CL, LoadNativeField of an unboxed slot always returned a boxed version of the value, which might be nice to eventually handle unboxing appropriately in optimized code but I figure that's a later improvement.

[sstrickl]

Just as a note, it's changed from always returning a boxed version to always returning an unboxed version, and allowing unboxed values on the expression stack in unoptimized code (still only when the unboxed values are added and consumed within a single basic block and not allowing calls while untagged values are on the stack).

Also, the first iteration of the backend changes only handles loads of kUnboxedUInt32 native fields (what I needed for this CL), so using it for the FFI implementation will need to both change the StoreField backend and extend the places in the LoadField backend that handles unboxed fields to handle Int64 (for archs where kUnboxedFfiIntPtr == kUnboxedInt64). (Am willing to do these changes since I already have the appropriate code paged in, but will do them as a separate CL.)

[sstrickl]

Just as a note, since the comments on here are now fairly out of date, Slots like those used in LoadNativeField/LoadFieldInstr have been adjusted to allow for native unboxed fields, and so LoadNativeField/LoadFieldInstr now works with these slots like any other.

I now have a CL that does the appropriate changes on the StoreInstanceFieldInstr side of things, and once that lands this can be closed.

[sstrickl]

Will leave this open even after the CL lands, because we should also see about migrating uses of LoadUntagged -> LoadField. (The CL mentioned in the last comment migrates all uses of StoreUntagged -> StoreInstanceField and removes StoreUntagged.)

[ds84182]

@dcharkes Some of the remaining usages of LoadUntagged in FFI is preventing the compiler from removing Pointer allocations.

import 'dart:ffi';

@pragma('vm:testing:print-flow-graph')
@pragma('vm:never-inline')
int bar(int l) => Pointer<Void>.fromAddress(l).address;

*** BEGIN CFG
After AllocateRegisters
==== file://<source>_::_bar (RegularFunction)
  0: B0[graph]:0 {
      v31 <- Constant(#TypeArguments: (H39d2e3b4) [Type: Never]) T{TypeArguments}
}
  2: B1[function entry]:2 {
      v2 <- Parameter(0) [-9223372036854775808, 9223372036854775807] T{int}
}
  3:     ParallelMove rdx <- C
  4:     v28 <- AllocateObject:24(cls=Pointer, v31 T{TypeArguments}) T{Pointer}
  5:     ParallelMove rax <- rax, rcx <- S+2
  6:     StoreField(v28 . PointerBase.data = v2 T{int} <int64>, NoStoreBarrier)
  8:     v18 <- LoadUntagged(v28 T{Pointer}, 8) T{*?}
 10:     v19 <- IntConverter(untagged->int64[tr], v18) T{int}
 11:     ParallelMove rax <- rcx
 12:     Return:14(v19 T{int})
*** END CFG

If I change some LoadUntagged instructions to LoadNativeField in kernel_to_il.cc the pointer allocation gets completely optimized out and the function becomes equivalent to int fn(int l) => l.

[dcharkes]

We should be able to get rid of the pointer allocation indeed.

@ds84182 would you like to make a PR?

(Related, we'd like to completely unbox pointer with function arguments and returns, so that we can also avoid allocations there. That would likely work somewhat similar to unboxed int/double params/returns. #50777)

[ds84182]

I can try to put together a CL either today or tomorrow. May be easier to do on my workstation once I'm not OOO