19×l3l4 19×l2l4 19×l1l4 = // ---------- // r4 r3 r2 r1 r0 // r0 = l0×l0 + 19×(l1×l4 + l2×l3 + l3×l2 + l4×l1) = l0×l0 + 19×2×(l1×l4 + l2×l3) r0 := mul(l0, l0) r0 = addMul38(r0, l1, l4) r0 = addMul38(r0, l2, l3) // r1 = l0×l1 + l1×l0 + 19×(l2×l4 + l3×l3 + l4×l2) = 2×l0×l1 + 19×2×l2×l4 + 19×l3×l3 r1 := mul(l0*2, l1) r1 = addMul38(r1, l2, l4) r1 = addMul19(r1, l3, l3) // r2 = l0×l2 + l1×l1 + l2×l0 + 19×(l3×l4 + l4×l3) = 2×l0×l2 + l1×l1 + 19×2×l3×l4 r2 := mul(l0*2, l2) r2 = addMul(r2, l1, l1) r2 = addMul38(r2,...

	// limit (8KB), we stop growing the source string once the limit
	// is reached and keep reusing the same source string - that
	// should therefore be always resident in the L1 cache - until we
	// have completed the construction of the result.
	// This yields significant speedups (up to +100%) in cases where
	// the result length is large (roughly, over L2 cache size).
	const chunkLimit = 8 * 1024

For instance, this example:
</p>

<pre>
if n%2 == 1 {
	goto L1
}
for n &gt; 0 {
	f()
	n--
L1:
	f()
	n--
}
</pre>

<p>
is erroneous because the label <code>L1</code> is inside
the "for" statement's block but the <code>goto</code> is not.
</p>

Shinsuke Sugaya <******@****.***> 1768400947 +0900

Yuri Schimke <******@****.***> 1770157079 +0000

Tamas Cservenak <******@****.***> 1771915648 +0100

Sebastián Ramírez <******@****.***> 1770902383 -0800

Carlos Amedee <******@****.***> 1769025172 -0500

Shinsuke Sugaya <******@****.***> 1774491848 +0900

renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> 1773997150 +0000