[PATCH] LLD: Remove YAML/Native round-trip passes

[Michael Spencer]

On Wed, Feb 11, 2015 at 4:37 PM, Rui Ueyama <ruiu at google.com> wrote:
> I found that Writing and reading Native files from YAML reader is actually
> tricky. Readers generally don't need a linking context, but writers do. So
> it's not easy to call a writer from a reader. Seems it needs a plumbing
> work.
>
> Then I tried to convert a YAML file to Native using yaml2obj -format=native.
> yaml2obj didn't actually support Native format because Native format lives
> only in LLD. Yet it's intended to be an alternative, hopefully better object
> file format, it's not supported by anyone except the linker. There's no
> consumer producing a file in that file format.

We haven't taught clang to produce it yet because the format isn't
finalized. The performance gain from it is still rather large, and I
feel it's an important feature.

>
> I started feeling I'm just wasting time. There are a lot of other things I
> need to do to make LLD a production quality linker, and this is not only
> non-productive but is actually counter-productive. Can you guys approve this
> patch so that I can submit this now?

I'm fine with this patch, but I don't want to completely remove
testing of the native format.

I suppose it's fine to commit now to remove blockage.

- Michael Spencer

>
> On Wed, Feb 11, 2015 at 2:08 PM, Rui Ueyama <ruiu at google.com> wrote:
>>
>> On Tue, Feb 10, 2015 at 7:27 PM, Rafael Espíndola
>> <rafael.espindola at gmail.com> wrote:
>>>
>>> I really like this.
>>>
>>> Every object file has peculiarities. MachO  has scattered relocations.
>>> Mips elf has many in one relocations.
>>>
>>> If we, with the handsight of having built a linker, create a rounder
>>> wheel, it will be just another file format. We will still have to parse it
>>> and report broken files. It will have to be able to represent the constructs
>>> that currently use the various features of existing formats, but calling it
>>> "native" and requiring direct mapping to it seems counter productive.
>>
>> I totally agree.
>>
>> What I'm thinking now is to convert a YAML file to Native and read it back
>> before doing anything to that YAML file, assuming YAML and Native are
>> compatible. YAML reader should be well-tested because there are many tests
>> written in YAML. So that test should be enough to test Native.
>>
>>>
>>> On Feb 6, 2015 9:40 PM, "Rui Ueyama" <ruiu at google.com> wrote:
>>>>
>>>> The round-trip passes were introduced in r193300. The intention of
>>>> the change was to make sure that LLD is capable of reading end
>>>> writing such file formats.
>>>>
>>>> But that turned out to be yet another over-designed stuff that had
>>>> been slowing down everyday development.
>>>>
>>>> The passes ran after the core linker and before the writer. If you
>>>> had an additional piece of information that needs to be passed from
>>>> front-end to the writer, you had to invent a way to save the data to
>>>> YAML/Native. These passes forced us to do that even if that data
>>>> was not needed to be represented neither in an object file nor in
>>>> an executable/DSO. It doesn't make sense. We don't need these passes.
>>>>
>>>> http://reviews.llvm.org/D7480
>>>>
>>>> Files:
>>>>   include/lld/Passes/RoundTripNativePass.h
>>>>   include/lld/Passes/RoundTripYAMLPass.h
>>>>   lib/CMakeLists.txt
>>>>   lib/Driver/CMakeLists.txt
>>>>   lib/Driver/Driver.cpp
>>>>   lib/Passes/CMakeLists.txt
>>>>   lib/Passes/Makefile
>>>>   lib/Passes/RoundTripNativePass.cpp
>>>>   lib/Passes/RoundTripYAMLPass.cpp
>>>>   lib/ReaderWriter/CMakeLists.txt
>>>>   lib/ReaderWriter/CoreLinkingContext.cpp
>>>>   lib/ReaderWriter/ELF/CMakeLists.txt
>>>>   lib/ReaderWriter/ELF/ELFLinkingContext.cpp
>>>>   lib/ReaderWriter/ELF/Makefile
>>>>   lib/ReaderWriter/MachO/CMakeLists.txt
>>>>   lib/ReaderWriter/MachO/MachOLinkingContext.cpp
>>>>   lib/ReaderWriter/PECOFF/CMakeLists.txt
>>>>   test/elf/Mips/pc23-range.test
>>>>   test/elf/roundtrip.test
>>>>   test/lit.cfg
>>>>   tools/lld/Makefile
>>>>   unittests/DriverTests/Makefile
>>>>
>>>> EMAIL PREFERENCES
>>>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>