[llvm] r205277 - Add a comment about type-uniquing ObjC types.

Adrian Prantl aprantl at apple.com
Tue Apr 1 12:58:03 PDT 2014


On Apr 1, 2014, at 12:12 PM, Eric Christopher <echristo at gmail.com> wrote:

> On Mon, Mar 31, 2014 at 8:41 PM, Adrian Prantl <aprantl at apple.com> wrote:
>> Author: adrian
>> Date: Mon Mar 31 22:40:59 2014
>> New Revision: 205277
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=205277&view=rev
>> Log:
>> Add a comment about type-uniquing ObjC types.
>> 
>> Modified:
>>    llvm/trunk/include/llvm/IR/DebugInfo.h
>> 
>> Modified: llvm/trunk/include/llvm/IR/DebugInfo.h
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/IR/DebugInfo.h?rev=205277&r1=205276&r2=205277&view=diff
>> ==============================================================================
>> --- llvm/trunk/include/llvm/IR/DebugInfo.h (original)
>> +++ llvm/trunk/include/llvm/IR/DebugInfo.h Mon Mar 31 22:40:59 2014
>> @@ -767,6 +767,8 @@ public:
>>     return (getUnsignedField(6) & dwarf::DW_APPLE_PROPERTY_nonatomic) != 0;
>>   }
>> 
>> +  /// Objective-C doesn't have an ODR, so there is no benefit in storing
>> +  /// the type as a DITypeRef here.
> 
> Any reason not to though?
I was thinking that it would make things slower without providing a benefit.

> I'm envisioning something like the same
> archive being lto'd twice via two things, etc. You'd want to be able
If it is actually the same archive, the DILexicalBlocks&friends should have identical MDNode representations and would be uniqued via FoldingSet magic.
> to unique it I'd think. It's a bit of a stretch I understand, but the
> uniformity might be nice.
Once someone comes along with an actual use case (currently I’m struggling to imagine one), it might also become more obvious what to use as the unique identifier in the DIScopeRef then.

If you’re only interested in the uniformity, every (actual) DIScope is also a valid DIScopeRef, but I think it would be misleading to treat them DIRefs when really they aren’t.

-- adrian



More information about the llvm-commits mailing list