[llvm-dev] RFC: LLVM Assembly format for ThinLTO Summary

[Eric Christopher via llvm-dev]

>
>>>>> I may be mistaken, but I don't think we have a lot of tools that can
>>>> read both .ll and .bc and end up using the summary if it is a .bc file. LTO
>>>> can't read .ll, for example.
>>>>
>>>
>>> Oh, I didn't know that - why doesn't it read .ll? That seems like an
>>> oversight - most/all the other LLVM tools treat .ll and .bc pretty equally,
>>> don't they?
>>>
>>
>> Yes, the developer-facing tools do (clang being one of them, as it has
>> some developer-facing features), but linkers (the LTO API consumers) are
>> user-facing, and have no need to consume .ll files. Getting them to read
>> .ll has other complications as well. For example, Unix linkers will
>> interpret textual input files as linker scripts, so there would need to be
>> some mechanism to distinguish .ll files from linker scripts.
>>
>
> Yeah, no worries about the linker - though I guess it could be convenient
> if it did some lookahead & could detect a .ll file as being different from
> a linker script - but that's a "nice to have"/heroics, not something I'd
> expect.
>
>
>> llvm-lto2 (the LTO API test driver) is a developer-facing tool, and we
>> could conceivably make it read .ll files and pass them to the API as .bc
>> files.
>>
>
> Right - this was more what I had in mind. Basically I'd find it weird if I
> came across an LLVM test case that first ran a .ll file through llvm-as,
> then ran it on the tool (llvm-lto2) in question. I'd likely try to remove
> the indirection & be a bit annoyed if that failed.
>
>
FWIW I'm in total agreement here :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180504/f480f4a0/attachment.html>