<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">The flag is on cpp record and only used when emitting CodeView debug info.</div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><a href="https://reviews.llvm.org/rL343626" style="caret-color: rgb(0, 0, 0); background-color: rgba(255, 255, 255, 0);"><font color="#000000">https://reviews.llvm.org/rL343626</font></a></div><div><br></div>On Apr 10, 2019, at 6:18 PM, Aaron Smith <<a href="mailto:aaron.lee.smith@gmail.com">aaron.lee.smith@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"></div><div dir="ltr">The flag is put on the cpp record. </div><div dir="ltr"><br></div><div dir="ltr"><a href="https://reviews.llvm.org/D59347">https://reviews.llvm.org/D59347</a></div><div dir="ltr"><br>On Apr 10, 2019, at 5:54 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>This is all assuming that both flags are only present when compiling with PDB debug info and zero when compiling for DWARF. Is that correct?</span><br><span></span><br><blockquote type="cite"><span>On Apr 10, 2019, at 3:52 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If it wasn't in the last LLVM release and nobody in the community released an LLVM-based product to users that use PDB debug info and LTO in the mean time, it will not be a big deal.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-- adrian</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Apr 10, 2019, at 3:50 PM, Aaron Smith <<a href="mailto:aaron.lee.smith@gmail.com">aaron.lee.smith@gmail.com</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I know very little about bitcode compatibility in llvm. Since both of these flags were added in the last two or three months this is probably not a big deal? The whole reason for the change is to reclaim the bit.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On Apr 10, 2019, at 4:43 PM, Adrian Prantl via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>aprantl added inline comments.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>================</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Comment at: include/llvm/IR/DebugInfoFlags.def:57-60</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>+HANDLE_DI_FLAG((1 << 26), NonTrivial)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>HANDLE_DI_FLAG((1 << 27), BigEndian)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>HANDLE_DI_FLAG((1 << 28), LittleEndian)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>HANDLE_DI_FLAG((1 << 29), AllCallsDescribed)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>----------------</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>dblaikie wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>@aprantl - could you review this for bitcode compatibility?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I  imagine reusing a bit for a different meaning (the exact opposite) would be problematic?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>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?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Since this only affects PDB debug info I personally don't worry about breaking bitcode compatibility, however other people may do so.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The correct way to update this is to bump the version of the records (DICompositeType) and parse the old or the new format accordingly.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>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.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>CHANGES SINCE LAST ACTION</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="https://reviews.llvm.org/D59348/new/">https://reviews.llvm.org/D59348/new/</a></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="https://reviews.llvm.org/D59348">https://reviews.llvm.org/D59348</a></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br></div></blockquote></div></blockquote></body></html>