tco and non-tco execution cannot be active at the same time

[Schaeff]

Since 1.4.1, turning on the tco feature removes the non-tco execution code.

This is an issue for us (powdr labs) for the following reason:

• We build specialised chips for whole blocks of the program
• Execution for these specialised chips relies on execution for the instructions of the block
• Whether in tco or in non-tco mode, we execute the block instructions in non-tco node.

As a result, we cannot support tco in 1.4.1, because turning tco on removes the code that we rely on for execution.

We tried fixing this by relying on tco execution only when in tco mode. This does not seem to work, because once we tco-execute the first instruction in the block, we don't have a way to stop at the end of the block, since tco execution only stops when it reaches a base case.

We would suggest switching back to the 1.4.0 behaviour, where the tco feature kept the non-tco code intact.

Tagging @shuklaayush following advice from @jonathanpwang

[shuklaayush]

I'll need to take a look at this. We seem to have a lot of #[cfg(not(feature = "tco"))] flags in the code now so this might be tricky

We tried fixing this by relying on tco execution only when in tco mode. This does not seem to work, because once we tco-execute the first instruction in the block, we don't have a way to stop at the end of the block, since tco execution only stops when it reaches a base case.

I'm not sure how you're executing the instructions but we do have a function in the Interpreter that suspends execution after a fixed number of instructions. Maybe this is useful?

[Schaeff]

Thanks for your feedback! This function is too high level but I'll check if we can use instret to stop at the end of the block.

[Schaeff]

I had a look. arg stands for instret_end only in the context of pure execution. This is what execute_from_state, which you shared, uses. However, we need execution in all modes.

This is how we do it using the non-tco executor (and in the tco one before 1.4.1) and it seems like it would be ideal to use that as well in tco.

I'm aware that removing this either-or compilation would likely lead to some name collisions, but it would really enable our use-case.

Thanks again for looking into this!