[llvm] r202417 - Revert r201751 and solve the const problem a different way - by

[Eric Christopher]

>> +  if (!Size) {
>> +    const SmallVectorImpl<DIEAbbrevData> &AbbrevData = Abbrev.getData();
>> +    for (unsigned i = 0, N = Values.size(); i < N; ++i)
>> +      Size += Values[i]->SizeOf(AP, AbbrevData[i].getForm());
>> +  }
>
> Should we add an assert here to make sure the Size isn't different
> from the cached size? (should we ever end up with a situation in which
> a caller computes the size, then adds things, then retrieves the size
> again - thus getting the incorrect, cached, size not the current size)
> - it would mean debug builds always compute the size, never relying on
> the cache, but release builds rely on it and don't recompute it.

We could add ... right. Um, sure, it seems reasonable :)

>>  void DwarfUnit::addBlock(DIE *Die, dwarf::Attribute Attribute, DIELoc *Loc) {
>> -  Loc->setSize(Loc->ComputeSize(Asm));
>> +  Loc->ComputeSize(Asm);
>>    DIELocs.push_back(Loc); // Memoize so we can call the destructor later on.
>>    Die->addValue(Attribute, Loc->BestForm(DD->getDwarfVersion()), Loc);
>>  }
>>
>>  void DwarfUnit::addBlock(DIE *Die, dwarf::Attribute Attribute,
>>                           DIEBlock *Block) {
>> -  Block->setSize(Block->ComputeSize(Asm));
>> +  Block->ComputeSize(Asm);
>
> Do we need to call ComputeSize here at all, then?
>

Interesting question - the brief answer is "yes" but only because
everything accesses by grabbing the Size member rather than calling
ComputeSize.

> (is "getSize" a better name for this function, rather than
> ComputeSize? I dunno - haven't looked at the hierarchy and callers,
> etc)

Totally. Yes.

-eric

>
>>    DIEBlocks.push_back(Block); // Memoize so we can call the destructor later on.
>>    Die->addValue(Attribute, Block->BestForm(), Block);
>>  }
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits