Bug 1647847 has a profile in which Object.assign is hot. We already optimized the native implementation in bug 1364854. If we want it to get any faster, we probably have to generate specialized code using ICs.

If the shapes of the inputs are consistent at a call site (which seems plausible, although I haven't verified for this particular case), then I think we could emit CacheIR that will GuardShape on the arguments, then load the required slots from the incoming objects and store them to the result object. It would require some refactoring of Load(Fixed|Dynamic)SlotResult (so that they can be used as an intermediate op, instead of results) and all the (Allocate|Add)AndStore(Fixed|Dynamic)Slot ops (to avoid reallocating / updating the shape repeatedly).

To get the result shape, we'd also have to do a trick similar to SetProp where we verify in tryAttach that there aren't any non-data properties, decide to generate an IC, store the input shapes, execute the operation, grab the result shape, and then attach an IC. CallIRGenerator already has support for deferring the attachment of stubs, although it's currently unused. (Note: storing the input shapes before executing the operation is important; SetProp had bugs because it got that part wrong.)

This only makes sense to work on post-Warp, since it won't improve Ion performance.

I tried this last week after bug 1696178 but it looked like the from-objects had shapes that were too unstable on Reddit and Slack. This was when I attached at most one specialized assign-stub for PlainObjects that guarded on all shapes (including the prototype chain shapes for the target object).

If I (unsoundly) removed the shape guards for the from-objects, the optimized stub succeeded most of the time but with those shape guards it didn't have a very good hit rate.