Bug 193869

What I have in mind to make it possible is to follow what we do with Strings right now. The idea is to use LazyJSValue, since we can only allocate heap objects after compilation is finished. In the case of LazyJaValues of BigInts, the plan is to record following information: 1. lhs and rhs operands; 2. Type of operation; To have a robust implementation and fold constants properly, lhs and rhs should be LazyJSValues that also can be computed on further steps. We need to change JSBigInt API to support arithmetic operations that can't fail due OOM. Also, we need to guarantee when constant fold happens that we won't overflow BigInt::maxSize.

Created attachment 360242 [details] WIP - Patch Here is a very simple version to illustrate what I have in mind now. I'm creating LazyBigIntValue to store required information to calculate BigInts properly. A LazyJSValue(NewBigInt) can have KnowValue or other LazyBigIntValue as operands. This enables us fold cascaded constants. The Folding is being done during Strengthreduction, following String rules as well.

(In reply to Caio Lima from comment #1) > What I have in mind to make it possible is to follow what we do with Strings > right now. The idea is to use LazyJSValue, since we can only allocate heap > objects after compilation is finished. In the case of LazyJaValues of > BigInts, the plan is to record following information: > > 1. lhs and rhs operands; > 2. Type of operation; > > To have a robust implementation and fold constants properly, lhs and rhs > should be LazyJSValues that also can be computed on further steps. > We need to change JSBigInt API to support arithmetic operations that can't > fail due OOM. > Also, we need to guarantee when constant fold happens that we won't overflow > BigInt::maxSize. I think we also can have a special case when BigInts are proven to be 64-bit.

Sounds good to me