catalyst icon indicating copy to clipboard operation
catalyst copied to clipboard

[LLVM] Patch LLVM to avoid cache when comparing mutually exclusive regions

Open erick-xanadu opened this issue 4 months ago • 2 comments

Context: Profiling large programs of interest found that this cache is problematic when compiling functions with very large bodies. This cache may be beneficial for medium sized programs. MLIR is not optimized for machine generated code where functions can be 100k lines of code. Removing this cache finds that the compilation time reduces a 20%.

Description of the Change: Patch LLVM to avoid using a cache for comparing mutually exclusive regions.

Benefits: Reduced compilation times for very large programs.

Possible Drawbacks: This may impact other smaller programs of interests. We need to purge the LLVM cache for these changes to be integrated correctly into the toolchain.

Related GitHub Issues:

Part 2 of [sc-93707]

erick-xanadu avatar Jul 08 '25 16:07 erick-xanadu

Thanks Erick, I found the PR in LLVM that adds the cache and based on the PR description, they claim that the cache would result in “noticeable” speedup for “large” programs depending on program “structure”.

IIUC, the main argument here is that a typical “large” program in MLIR ecosystem is not actually very large compared to what we see in the case of XAS benchmark (10k+ vs 100k+), and so that is why we see the degradation due to the cache.

I think by removing the cache, we are guaranteed to see some degradation of compile time in other medium-size benchmarks if we capture similar program structures that the LLVM PR was tested on. Even if we don’t see it now, we may see it in future when the benchmarks expand (at that point, we won’t even know there is a degradation until we profile pass times).

The question is how much that degradation is and whether it is tolerable for us. This can be more clear when we compare the benchmark results with this PR.

mehrdad2m avatar Jul 10 '25 00:07 mehrdad2m

The question is how much that degradation is and whether it is tolerable for us. This can be more clear when we compare the benchmark results with this PR.

I agree. This is why this PR is something that may not be advisable to merge. It is a question of how bad the performance will be for medium sized programs vs how much we benefit from the impact of really big programs. Someone has to give a weight to our benchmarks, but it is hard to say.

erick-xanadu avatar Jul 10 '25 16:07 erick-xanadu