My understanding was that clang isn’t deterministic by default but can be made deterministic with flags. I checked and this is still true but not for the reasons I thought. I assumed this was due to the way LLVM iterates over functions and basic blocks in a non-deterministic order (because of the way they are laid out in memory) and because some optimisations use heuristics. But it appears LLVM tries to make all optimisation passes deterministic. The remaining non-determinism comes from file paths and timestamps which can be worked around with the correct flags and some extra work to create reproducible builds.
Thank you very much for looking it up! I learned something new thanks to you.
So I guess in the end it is deterministic, because for a given set of inputs it always produces the same output, it’s just that file paths and timestamps must also be considered as input.
I don’t think that’s true - or thst it is a bug. It would make reproducible builds impossible.
My understanding was that clang isn’t deterministic by default but can be made deterministic with flags. I checked and this is still true but not for the reasons I thought. I assumed this was due to the way LLVM iterates over functions and basic blocks in a non-deterministic order (because of the way they are laid out in memory) and because some optimisations use heuristics. But it appears LLVM tries to make all optimisation passes deterministic. The remaining non-determinism comes from file paths and timestamps which can be worked around with the correct flags and some extra work to create reproducible builds.
Thank you very much for looking it up! I learned something new thanks to you.
So I guess in the end it is deterministic, because for a given set of inputs it always produces the same output, it’s just that file paths and timestamps must also be considered as input.