[PATCH] D59348: [DebugInfo] Combine Trivial and NonTrivial flags

Aaron Smith via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 10 16:38:24 PDT 2019


The flag is on cpp record and only used when emitting CodeView debug info.

https://reviews.llvm.org/rL343626

> On Apr 10, 2019, at 6:18 PM, Aaron Smith <aaron.lee.smith at gmail.com> wrote:
> 
> The flag is put on the cpp record. 
> 
> https://reviews.llvm.org/D59347
> 
>> On Apr 10, 2019, at 5:54 PM, Adrian Prantl <aprantl at apple.com> wrote:
>> 
>> 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?
>> 
>>> On Apr 10, 2019, at 3:52 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>> 
>>> 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.
>>> 
>>> -- adrian
>>> 
>>>> On Apr 10, 2019, at 3:50 PM, Aaron Smith <aaron.lee.smith at gmail.com> wrote:
>>>> 
>>>> 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.
>>>> 
>>>>> On Apr 10, 2019, at 4:43 PM, Adrian Prantl via Phabricator <reviews at reviews.llvm.org> wrote:
>>>>> 
>>>>> aprantl added inline comments.
>>>>> 
>>>>> 
>>>>> ================
>>>>> Comment at: include/llvm/IR/DebugInfoFlags.def:57-60
>>>>> +HANDLE_DI_FLAG((1 << 26), NonTrivial)
>>>>> HANDLE_DI_FLAG((1 << 27), BigEndian)
>>>>> HANDLE_DI_FLAG((1 << 28), LittleEndian)
>>>>> HANDLE_DI_FLAG((1 << 29), AllCallsDescribed)
>>>>> ----------------
>>>>> dblaikie wrote:
>>>>>> @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?
>>>>> 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.
>>>>> 
>>>>> 
>>>>> CHANGES SINCE LAST ACTION
>>>>> https://reviews.llvm.org/D59348/new/
>>>>> 
>>>>> https://reviews.llvm.org/D59348
>>>>> 
>>>>> 
>>>>> 
>>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190410/5abce4e7/attachment.html>


More information about the llvm-commits mailing list