[LlvmIrGenerator] ~4x faster type map generation

[jonathanpeppers]

Fixes a hot spot in LlvmIrGenerator that dominates <GenerateTypeMappings/>, and unifies three copies of "bytes → hex" while we're in there.

The problem

WriteStringBlobArray() emits one LLVM IR element per byte of the type-map string blobs — 3,630,285 calls for a hello-world MAUI app (96.5% of all elements in the 52.6 MB .ll). Each one went through WriteType() + WriteValue(), which do Type.IsPrimitive, TypeUtilities.IsArray(), IsSubclassOf(), plus boxing and several string allocations — all to emit the constant i8 and two hex digits.

The fix

1. Write bytes directly in the blob loop: "i8 u0x" + two hex chars. No reflection, no allocation.
2. Basic-type fast path in WriteType() — basicTypeMap.ContainsKey() short-circuits the reflection probing. Safe because nothing in basicTypeMap can be a structure instance, array, sectioned array or string blob. This helps all callers, including the 132,549 i32 struct fields.

Results

dotnet new maui -sc, CoreCLR, GenerateTypeMappings on a clean build:

before	after
3,204 ms	792 ms

~4× faster, −2.4 s. Measured by reverting only LlvmIrGenerator.cs against an otherwise identical SDK build, so nothing else varied.

Output is byte-identical: typemaps.arm64-v8a.ll SHA256 D875D690… across every run, before and after.

HexUtilities.cs

We had three private hex implementations. They're now one public static class HexUtilities in Microsoft.Android.Build.BaseTasks:

was	now
Files.GetHexValue() / Files.ToHexString()	HexUtilities.ToHexString()
ScannerHashingHelper.ToHexString() / GetHexValue()	HexUtilities.ToHexString (hash, upperCase: false)
(new) generator hot path	HexUtilities.WriteHex (TextWriter, byte, …)

API: GetHexValue(), WriteHex(Span<char>, …), WriteHex(TextWriter, …) (no stackalloc), ToHexString(). The upperCase flag exists because Files emits uppercase while ScannerHashingHelper and LLVM IR emit lowercase.

Microsoft.Android.Sdk.TrimmableTypeMap still source-links the file — a ProjectReference to BaseTasks would drag in Microsoft.Build.*, LibZipSharp (native assets), K4os.LZ4 and Mono.Unix. That linked copy stays internal via one #if, since two public Microsoft.Android.Build.Tasks.HexUtilities types make Xamarin.Android.Build.Tasks fail with CS0433 (it references both assemblies).

Measured and rejected

Short-circuiting all numeric writes saved ~33 ms of ~1,500 ms — noise. Not worth an i32 fast path; the rest is mostly I/O for a 52.6 MB file.

The real remaining win is emitting c"..." string literals instead of per-byte i8 arrays (~52.6 MB → ~5 MB), which would also cut llc time. Left for a follow-up.

Testing

• Microsoft.Android.Build.BaseTasks-Tests: 129/129 (was 107 — 22 new HexUtilities tests)
• LlvmIrGeneratorTests: 9/9
• Xamarin.Android.sln builds clean

[Copilot]

Pull request overview

This PR reduces <GenerateTypeMappings/> time by removing per-byte reflection/boxing overhead in LlvmIrGenerator and consolidating duplicated “bytes → hex” logic into a single shared HexUtilities helper.

Changes:

• Optimized string-blob IR emission by writing i8 u0xNN directly for each byte and adding a basic-type fast path in WriteType().
• Introduced HexUtilities in Microsoft.Android.Build.BaseTasks and switched existing hex call sites (Files, ScannerHashingHelper) to use it.
• Added dedicated unit tests for HexUtilities.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tests/Microsoft.Android.Build.BaseTasks-Tests/HexUtilitiesTests.cs	Adds coverage for GetHexValue, WriteHex, and ToHexString behaviors (upper/lowercase, boundaries).
src/Xamarin.Android.Build.Tasks/Utilities/LlvmIrGenerator/LlvmIrGenerator.cs	Removes hot-path overhead by emitting byte constants directly and short-circuiting primitive type handling.
src/Microsoft.Android.Sdk.TrimmableTypeMap/Scanner/ScannerHashingHelper.cs	Replaces local hex formatting with shared HexUtilities (lowercase).
src/Microsoft.Android.Sdk.TrimmableTypeMap/Microsoft.Android.Sdk.TrimmableTypeMap.csproj	Source-links the shared HexUtilities.cs file into the TrimmableTypeMap project.
src/Microsoft.Android.Build.BaseTasks/Microsoft.Android.Build.BaseTasks.csproj	Defines a compile constant to make HexUtilities public only in BaseTasks.
src/Microsoft.Android.Build.BaseTasks/HexUtilities.cs	New shared implementation for allocation-free hex rendering.
src/Microsoft.Android.Build.BaseTasks/Files.cs	Replaces in-file hex conversion with HexUtilities.ToHexString().

Suppressed comments (3)

src/Microsoft.Android.Build.BaseTasks/HexUtilities.cs:67

• 🤖 ⚠️ warning Formatting — Mono style requires a space before [ in array/stackalloc expressions. This avoids mixing standard C# formatting with the repo’s convention.

			Span<char> chars = charLength <= MaxStackCharLength
				? stackalloc char[charLength]
				: new char[charLength];

src/Microsoft.Android.Build.BaseTasks/HexUtilities.cs:41

• 🤖 ❌ error API design — WriteHex(Span<char> destination, ...) assumes destination.Length >= 2 and otherwise throws IndexOutOfRangeException. Since this helper is public in BaseTasks, validate the span length and throw an ArgumentException with a clear message.

		public static void WriteHex (Span<char> destination, byte value, bool upperCase = true)
		{
			destination [0] = GetHexValue (value >> 4, upperCase);
			destination [1] = GetHexValue (value & 0x0f, upperCase);
		}

src/Microsoft.Android.Build.BaseTasks/HexUtilities.cs:30

• 🤖 ⚠️ warning Formatting — This repo uses Mono style spacing; casts should be written with a space (e.g. (char) (value + '0')) for consistency with the rest of BaseTasks.

			if (value < 10)
				return (char)(value + '0');
			return (char)(value - 10 + (upperCase ? 'A' : 'a'));

[jonathanpeppers]

Went through the review feedback -- checked each item against the actual repo rather than taking it at face value. Fixes in 195cab0.

Applied

Feedback	Outcome
WriteHex(Span<char>) should validate length	Fair -- it is public now, so IndexOutOfRangeException is a poor contract. Throws ArgumentException instead, + 3 tests.
Cast spacing (char) (	Repo is 49:2 in favour.
stackalloc char [n] spacing	Repo is 30:16 in favour.

Both spacing issues came from copying the Files.cs code this replaces verbatim.

Tests: 126 -> 129 passing.

Declined

• #endif annotation -- not the repo convention (17 bare vs 11 annotated in these two projects), and the extra cited locations are not preprocessor directives.
• Redundant dictionary lookup in the WriteType() fast path -- the suggested fix would skip MapToIRType()'s native-pointer handling, and the measured ceiling for all numeric writes is ~33 ms of ~1,500 ms. Details in the thread.

[jonathanpeppers]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[github-actions]

🤖 Code Review — ⚠️ minor suggestions

Strong, well-scoped PR. I read the changed files in full and independently verified the key claim: the byte-write fast path and WriteType() basic-type short-circuit are behavior-preserving.

Verification

• WriteByteTypeAndValue: original WriteType()+WriteValue() emitted i8 + u0x + {b:x02} (2 lowercase hex). New code emits "i8 u0x" + HexUtilities.WriteHex(..., upperCase: false) — byte-for-byte identical. It's only ever reached from WriteStringBlobArray(), which forces NumberFormat = Hexadecimal and elementType = byte, so the hardcoded values are safe today.
• WriteType() fast path: nothing in basicTypeMap can be a structure/array/sectioned-array/string-blob, and the constructed LlvmTypeInfo matches the general GetIRType() path (lines 535–542) exactly. Equivalent output, less reflection.
• HexUtilities unification: casing preserved per caller — Files.ToHexString stays uppercase (default upperCase: true); ScannerHashingHelper and the generator pass upperCase: false. The #if MICROSOFT_ANDROID_BUILD_BASETASKS public/internal split correctly avoids CS0433 in Xamarin.Android.Build.Tasks.
• Tests: 22 new tests cover casing, the 2-char span contract, null TextWriter, all 256 byte values, empty input, and the 128-char stackalloc threshold — thorough.

CI

GitHub-surfaced Azure DevOps checks are green (Java.Interop + Android Tools tests passing); Linux/Mac/Windows build legs still in progress at review time. No failures observed.

Suggestions (non-blocking, posted inline)

• 💡 Guard the hidden i8/hex invariant in WriteByteTypeAndValue with a Debug.Assert.
• 💡 Now-public GetHexValue silently produces garbage for out-of-range input — consider a Debug-only assert.

Nice work, especially the measured-and-rejected notes and byte-identical .ll SHA verification. 👍

Generated by Android PR Reviewer for #12279 · 124.2 AIC · ⌖ 18.7 AIC · ⊞ 6.9K
_{Comment /review to run again}