llvm dev - Jul 2014 - [LLVMdev] Clarification on the backward compatibility promises

> 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.

Evan
> 
> -eric
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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

On Jul 9, 2014, at 3:51 PM, Eric Christopher <echristo at gmail.com>
wrote:
> 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.
That’s not really a practical suggestion for clients that aren’t essentially
clang.  The bar to changing the IR is (correctly) very high, essentially
unreachable if the client is out-of-tree.

—Owen



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