Consider storing auto-generated error message strings in separate object file #37512
Labels
A-codegen
Area: Code generation
A-incr-comp
Area: Incremental compilation
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
I-compiletime
Issue: Problems and improvements with respect to compile times.
I-slow
Issue: Problems and improvements with respect to performance of generated code.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Some kinds of expression can generate a runtime panic with a compiler generated error message containing the source location of that expression. Examples are arithmetic expressions that can cause integer overflow or division by zero, and expressions that result in array bounds checks.
So far we are allocating string constants in the same codegen unit as the expression, which has two disadvantages:
Because we do not check whether there is already a constant for that source location, we will have copies of the same data for each monomorphized instance of a function. (Or does LLVM merge equal constants if there address is never taken?)
Since the source location is contained in machine code, the whole object file often has to be re-compiled during incremental compilation even if just formatting has changed or comments have been added.
This could be solved by interning all those constants into a separate object file with a (semi-)stable symbol name (e.g. symbol_name = function_symbol_name + index within function). That way, only the error-message-object-file has to be regenerated when nothing but formatting has changed.
The text was updated successfully, but these errors were encountered: