This patch is a draft implementation of 64-bit source locations in
Clang. The intent is to evaluate viability of using 64-bit source
locations.
The patch implements a compile-time switch for the bit width of source
locations.
The libclang ABI is unchanged, regardless of that compile-time switch.
So libclang clients will only be able to handle compilations whose
source locations all fit in 32 bits; internal clang SourceLocations
are bounds-checked before converting them to the libclang types, and
replaced with the 'null location' error indicator if the bounds check
fails.
This patch is a joint effort between Mikhail Maltsev and Simon Tatham.
Mikhail performed two benchmarks on a previous version of the patch to
evaluate the effects of the patch on memory consumption and
performance:
- LLVM+Clang release build:
- Average memory usage during a parallel (32 thread) build increased by 8.333 ± 0.185 % (95 % confidence interval)
- Peak memory usage increased by 8.319 ± 1.680 %
- Total time increased by 0.669 ± 0.047 %
- Parsing and semantic analysis (i.e. -fsyntax-only) of a large C++ source file from the LLVM LNT test suite: https://github.com/llvm/llvm-test-suite/tree/main/MultiSource/Benchmarks/tramp3d-v4
- Memory usage increased by 8.97 % (exact measurement)
The current version should improve on that somewhat, but no
measurements are available yet.
I think allowing these to grow is likely a bad tradeoff -- we're paying 8 bytes per declaration in order to make only ObjCContainerDecls smaller (actually, not even that -- there'll be 4 bytes of padding in an ObjCContainerDecl either way in 64-bit-SourceLocation mode). Can you try moving the SourceLocation out of ObjCContainerDeclBitfields and into ObjCContainerDecl and see if that makes a noticeable difference to the memory overhead of this patch?