feat: add native u128 type

[TomAFrench]

Description

Problem*

Resolves

Summary*

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[kashbrti]

The following programs all fail with failed assertions for the addition and subtraction and overflows for mul and div,

#[test]
fn test_u128_sub() {
    let a: u128 = 671967750576550571863734675757137222;
    let b = 671967750576550571863734675757137221; 
    let c = a -1;  
    assert(c == b);
}


#[test]
fn test_u128_add() {
    let a: u128 = 671967750576550571863734675757137222;
    let b: u128 = 671967750576550571863734675757137221; 
    let c: u128 = b+1;  
    assert(c == a);
}

#[test]
fn test_u128_mul() {
    let a: u128 = 671967750576550571863734675757137222;
    let b: u128 = 335983875288275285931867337878568611; 
    let c: u128 = b* 2;  
    assert(c == a);
}

#[test]
fn test_u128_div() {
    let a: u128 = 671967750576550571863734675757137222;
    let b: u128 = 335983875288275285931867337878568611; 
    let c = a / 2;  
    assert(c == b);
}

I'm running the code after running noirup --pr 7301

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: 8159a92	Previous: 093a8ec	Ratio
AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_blob	66 s	54 s	1.22

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[TomAFrench]

@asterite Can you take over this PR? I'm not sure that I can devote enough time to it atm.

Remaining things to do include:

• Solve the overflow issue
• Block creation of the i128 type (we can potentially add this in future but I don't think we should add this in this PR)
• Add an SSA pass which lowers multiplication and division of u128s into being implemented in smaller types for which we can perform these operations safely
  • We have implementations for the U128 struct here which can be used as inspiration:

    noir/noir_stdlib/src/uint128.nr

    Lines 198 to 211 in 582f56e

    	fn mul(self: Self, b: U128) -> U128 {
    	assert(self.hi * b.hi == 0, "attempt to multiply with overflow");
    	let low = self.lo * b.lo;
    	let lo = low as u64 as Field;
    	let carry = (low - lo) / pow64;
    	let high = if crate::field::modulus_num_bits() as u32 > 196 {
    	(self.lo + self.hi) * (b.lo + b.hi) - low + carry
    	} else {
    	self.lo * b.hi + self.hi * b.lo + carry
    	};
    	let hi = high as u64 as Field;
    	assert(hi == high, "attempt to multiply with overflow");
    	U128 { lo, hi }
    	}

  • addition (and potentially subtraction) should be safe to leave as is.
  • This pass should only affect ACIR functions as brillig has full support for u128 types.
• Add more selective version of this check: https://github.com/noir-lang/noir/pull/7301/files#diff-7c64342380b96ff80bc78d976a826185fbf2f08c0a10d77318dde72f697cb3b7 which only blocks unsafe operations.
• A bunch of tests

[asterite]

Add an SSA pass which lowers multiplication and division of u128s into being implemented in smaller types for which we can perform these operations safely

Is there an operation that currently fails for this? I'm mainly trying to understand how it fails in order to understand how to implement this.

Add more selective version of this check

Why is that check needed? I know it says "for the truncation technique" but where is that, and why every math operation needs this check?

[TomAFrench]

Is there an operation that currently fails for this? I'm mainly trying to understand how it fails in order to understand how to implement this.

The issue is that the bn254 field can only represent numbers up to ~2^253 safely as otherwise we overflow the field modulus. If we then multiply 2 128 bit numbers together it's possible that we'll wrap around the field modulus and get a "small" result, this will then pass the overflow check as it fits within 128 bits. This isn't an issue for the other types as they're small enough that we'll never overflow the field.

We then want to make sure that there's no operations which we do in ACIR gen which can overflow the field modulus. These should then be lowered to be implemented in terms of the smaller types to avoid the potential for an uncaught overflow.

[TomAFrench]

LGTM