Companion to https://reviews.llvm.org/D59347
Details
Diff Detail
Event Timeline
include/llvm/IR/DebugInfoFlags.def | ||
---|---|---|
58–62 | @aprantl - could you review this for bitcode compatibility? I imagine reusing a bit for a different meaning (the exact opposite) would be problematic? Would we have to settle for keeping the bitcode encoding as 1=trivial 0=nontrivial (only for structs/classes? Maybe enums too?) - or burn the 26th bit and keep the 30th bit as NonTrivial? |
include/llvm/IR/DebugInfoFlags.def | ||
---|---|---|
58–62 | Since this only affects PDB debug info I personally don't worry about breaking bitcode compatibility, however other people may do so. The correct way to update this is to bump the version of the records (DICompositeType) and parse the old or the new format accordingly. If this isn't done any LLVM module with bitcode that currently uses bit 30 (which is now > Largest) will cause a verifier error and the debug info from that module will be dropped with a warning. LTO users may or may not care about this. |
If the NonTrivial flag was not present in the last open source release and none of the Windows stakeholders object, I think we can land this as a bugfix, ignoring bitcode compatibility.
@aprantl - could you review this for bitcode compatibility?
I imagine reusing a bit for a different meaning (the exact opposite) would be problematic?
Would we have to settle for keeping the bitcode encoding as 1=trivial 0=nontrivial (only for structs/classes? Maybe enums too?) - or burn the 26th bit and keep the 30th bit as NonTrivial?