Stack too deep errors with via-IR for some compilation routines

[CodeSandwich]

Description

I'm building a fairly large project using via-IR, here's the specific commit: https://github.com/drips-network/contracts/tree/57b0da62aceb0eb382c0d0472e53c1b42b962ebb. Depending on how the compilation is organized, the result may or may not be the stack too deep error.

Environment

• Compiler version: 0.8.24
• Target EVM version (as per compiler settings): shanghai
• Framework/IDE (e.g. Truffle or Remix): Foundry
• EVM execution environment / backend / blockchain client: Anvil
• Operating system: Linux

Steps to Reproduce

I can't provide a minimal example because the stack too deep errors only show up for large projects. Here are the steps to do after cloning the repository and installing Foundry. First of all, enable via-IR in the project:sd

export FOUNDRY_PROFILE=optimized

The failing routine

Clean up the Foundry compilation cache:

foundry clean

Build the project with all the tests and run them:

foundry test

The result is the stack too deep error:

Error: 
Compiler run failed:
Error: Yul exception:Cannot swap Variable var_idx with Variable _mpos_2: too deep in the stack by 1 slots in [ var_idx _mpos_2 var_accountId var_squeezeEndCap var_squeezeStartCap cleaned_4 cleaned_3 var_i_1 _mpos_1 var_amt var_currCycleConfigs RET var_squeezedRevIdxs_mpos var_squeezedNum dataSlot_3 var_streamsHistory_mpos _mpos_3 _mpos_2 ]
memoryguard was present.
memoryguard was present.

The succeeding routine

Clean up the Foundry compilation cache:

foundry clean

Build the project without the tests:

foundry build --skip test

Build the project again, this time with all the tests and run them:

foundry test

The result is a successful compilation and tests being executed.

Additional context

These results are reproducible, I tried both of them a few times and they always behave the same. I don't know if this is a Foundry issue or a Solc issue, I don't know how caching of the artifacts works and which component is responsible for putting them together in a reproducible way. This issue may or may not be even connected to the stack too deep issue at all, it could be only that this is an edge case where a caching issue causes a more visible result.

This is not necessarily an issue for the stack too deep error itself, it's already well known and has a few issues opened: #14358, #14187, #14179 and #14067, #13906.