[lld] r217324 - Remove dead code.

[Rui Ueyama]

As a thought experiment and a counter example, we could imagine if we adopt
that "metadata model" to the current LLD code base. We would remove the
following member functions from DefinedAtom in favor of the generic
key-value pair.

  ordinal()
  size()
  scope()
  merge()
  alignment()
  sectionChoice()
  customSectionName()
  and more ...

ordinal() would be rewritten as getAttribute(DefinedAtom::Ordinal), for
example. It seems apparent degradation in code quality to me.

On Mon, Nov 10, 2014 at 5:03 PM, Shankar Easwaran <shankare at codeaurora.org>
wrote:

> On 11/10/2014 6:55 PM, Rui Ueyama wrote:
>
>> On Mon, Nov 10, 2014 at 12:34 PM, Shankar Easwaran <
>> shankare at codeaurora.org>
>> wrote:
>>
>>    2) Add a generic dictionary method to lld::File.  The dictionary might
>>> be
>>>
>>>> empty for ELF and COFF readers, but the mach-o reader would populate the
>>>>>>> dictionary with some key/value encoding for each attribute it needs
>>>>>>> (e.g.
>>>>>>> “minOS” —> “10.9”).
>>>>>>>
>>>>>>>  I would like this, lld::File would become more flavor neutral with
>>>>>>
>>>>> this. For example if you add minOS to lld::File it would not make
>>>>> sense for
>>>>> COFF/ELF.
>>>>>
>>>>>  There will be a default (do nothing) implementation for these methods
>>>> in
>>>> the base class File.  COFF and ELF can just ignore them.  The dictionary
>>>> design is not a normal C++ pattern.
>>>>
>>>>  The LLVM IR also uses a metadata/dictionary model, to store attributes
>>> that are associated with the module. I think we also need a model that we
>>> can associate metadata with atoms.
>>>
>>
>> Yeah, I'd guess that's sometimes useful indeed. I once hoped to have
>> something like that because it would be convenient. But at the same time,
>> there's a risk that it becomes a kitchen sink that we put everything there
>> in an disorganized manner. Named fields and named accessors are, on the
>> other hand, organized and type-safe. LLVM IR and the internal
>> representation of object files in LLD are naturally different. I'd think
>> adding a generic key-value store to an atom is too flexible for us.
>>
>
> I think adding a metadata model, is more cleaner than adding flavor /
> target specific attributes in the Atom model.
>
> We could have specific keys, that access metadata information, rather than
> flavors adding any arbitrary set of keys (Best of both worlds).
>
> With this both LLVM IR, lld's IR both would share the same design too.
>
> Shankar Easwaran
>
>
>>  Shankar Easwaran
>>>
>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>>> by the Linux Foundation
>>>
>>>
>>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141110/c4eb9d41/attachment.html>