[LLVMdev] Clarification on the backward compatibility promises

[Eric Christopher]

On Wed, Jul 9, 2014 at 3:12 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
>> On Jun 17, 2014, at 2:10 PM, Eric Christopher <echristo at gmail.com> wrote:
>>
>>>> 2. Metadata compatibility. We already had precedence of introducing
>>>> incompatible changes into metadata format in the past within release.
>>>> Should we use relaxes rules for metadata compatibility?
>>>
>>> I think we have a special case for debug metadata (and should document
>>> that), but otherwise I think we should hold metadata to the same
>>> standard as the rest of the IR.
>>>
>>
>> The idea with metadata is that it can be removed and everything still
>> works. I'm definitely not ready to lock down the debug metadata format
>> and I really don't think we should for any of the other uses since
>> stripping already works. (Note, I don't consider function attributes
>> etc as metadata)
>
> We may need to rethink this. If metadata is used only as optimization / codegen hints, then yes I agree they can be dropped. But I suspect there is a need for metadata that’s *required* for correctness. As LLVM continues to gain clients beyond “just” compilers, we will need to be sensitive to their needs. I anticipate use of LLVM bitcode files as persistent object format.
>

I think that metadata that's required for correctness should be baked
into the IR and not be metadata - so if there's something we need for
correctness we need to come up with an IR extension. See the recent
comdat work as an example.

Sadly, I agree with you that bitcode might be a persistent object
format - I'd personally want an LLVM 3.0 that came up with a better
format though.

-eric