Optimise codegen for constant segments in bit arrays on JS

[richard-viney]

Currently when targeting JS the compiler converts

const data = <<0x1122:16>>

into this:

const data = /* @__PURE__ */ toBitArray([
  sizedInt(0x1122, 16, true),
]);

However, because all inputs are constant this could instead be evaluated at compile time to give more optimal output:

export const data = /* @__PURE__ */ toBitArray([
  17, 34,
]);

This is much faster to evaluate and also reduces JS code size, albeit only in the case when everything is constant. In my case this change would be quite significant on some large lookup tables.

This change would also have a secondary effect of adding support for arbitrarily sized constant integers in bit array expressions on JS, as the compiler would parse the input and convert to byte representation, i.e.

const data = <<0:128>>
const data = <<0x11223344556677881122334455667788:128>>

would compile to

const data = /* @__PURE__ */ toBitArray([
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
  17, 34, 51, 68, 85, 102, 119, 136, 17, 34, 51, 68, 85, 102, 119, 136,
]);

---

Outstanding questions are:

1. The num-bigint crate or similar would need to be added as a dependency to compiler-core. Is this ok?
2. The same idea applies to constant floats. Should they be changed to compile-time evaluation at the same time?
3. Are there any other downsides, issues, or points I've missed?

---

Note that constant strings in bit arrays can also be compile time evaluated, but the raw bytes would be larger than the quoted string, so the cost/benefit isn't as clear.

[lpil]

Is there much value in this? Seeing as constants are only evaluated once. I'd be surprised if the different was measurable let along impactful.

[richard-viney]

1. Applies to all constant segments in bit arrays

Yes for top-level constants which are evaluated once the performance difference is not worth it. However, this proposal applies to any constant segment that's part of a bit array construction, i.e. it's not limited to top-level constants. I didn't give a specific example of this, but code such as

pub fn go(s: String) { <<s:utf8, 0.0:64-float, 0x123456789ABC:48>> }

also benefits because the two constant segments get compile-time evaluated. The above function is ~2x faster with this proposal, and ~3x faster when combined with #3725.

A real-world benchmark I have is a large lookup table of 24,000 16-bit integers. It evaluates ~21x faster with this proposal when combined with #3725, but given that it's a top-level constant that performance gain is not important. However, its generated JS code is 185KiB (52%) smaller post esbuild --minify, which is more meaningful.

2. Fixes arbitrarily-sized constant integers in bit arrays

This proposal can fix arbitrarily-sized constant integers in bit array expressions on JS, if desired. These are currently subject to JS' number quantising limitations, but no longer would be:

pub fn main() {
  // This is currently False on JS, but would change to True
  <<0xFFFFFFFFFFFFFFFF:64>> == <<0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF>>

  let i = 0xFFFFFFFFFFFFFFFF

  // This remains False on JS, as the use of `i` triggers the limitations of a JS number,
  // unless we determined that `i` is a compile-time constant and evaluated it
  <<i:64>> == <<0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF>>
}

If it's the case that Gleam makes no guarantees about what happens when the limits of the target's integer type are hit, then this change could be made. Is existing code permitted to rely on such behaviour on JS? I can't see any reason to do so, as you'd get a different bit array on each target.

The fact the result is different when pulling out let i = 0xFFFFFFFFFFFFFFFF and doing <<i:64>> may be a non-starter though.

If the behaviour can't change here, then limiting compile-time evaluation to integers <= 48 bits wide would maintain all current behavioural edge cases. Most would fit under this limit.

[lpil]

Ah! You mean literals rather than constants! Sounds like a great idea!

We would need to determine if we consider this JS behaviour a change in semantics or not. I could see the argument either way. I think a good solution might be to emit a warning when an int is too large for JavaScript to represent accurately.

[richard-viney]

Implemented in #3724