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

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>

On Wed, Jul 9, 2014 at 9:33 PM, Owen Anderson <resistor at mac.com>
wrote:
>
> 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.
>
Sure, but they likely have their own metadata format with their own
needs and can keep their own local patches for their out of tree
extensions right? As far as I know we don't have any metadata
extensions in tree that are required for any correctness. If so,
they've explicitly gone against the rules we set for metadata a long
time back:

http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html

Unless I'm missing your point completely of course :)

-eric

On 07/09/2014 09:33 PM, Owen Anderson wrote:
>
> On Jul 9, 2014, at 3:51 PM, Eric Christopher <echristo at gmail.com 
> <mailto:echristo at gmail.com>> wrote:
>
>> On Wed, Jul 9, 2014 at 3:12 PM, Evan Cheng <evan.cheng at apple.com 
>> <mailto:evan.cheng at apple.com>> wrote:
>>>
>>>> On Jun 17, 2014, at 2:10 PM, Eric Christopher <echristo at
gmail.com
>>>> <mailto: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.
My response as someone with such an out of tree client: that's their 
problem.  We should consider adding obvious (and merge safe!) extension 
points, but we have no responsibility to preserve out of tree semantics 
which explicitly go against stated guidelines.

Also, while the bar for changing the IR is high, I haven't actually seen 
that many well thought out proposals rejected.  I have also not seen 
many rejected without solid reasoning and a recommendation for a 
preferred approach.

Philip

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

> On Jul 9, 2014, at 9:52 PM, Eric Christopher <echristo at gmail.com>
wrote:
> 
> On Wed, Jul 9, 2014 at 9:33 PM, Owen Anderson <resistor at mac.com>
wrote:
>> 
>> 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.
>> 
> 
> Sure, but they likely have their own metadata format with their own
> needs and can keep their own local patches for their out of tree
> extensions right? As far as I know we don't have any metadata
> extensions in tree that are required for any correctness. If so,
> they've explicitly gone against the rules we set for metadata a long
> time back:
> 
> http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html
> 
> Unless I'm missing your point completely of course :)
I don’t disagree with this. I am only cautioning against taking an absolutely
hardline attitude towards metadata compatibility. As long as we take a pragmatic
approach by providing ways for clients to maintain backward compatibility, I
don’t think anyone will have problems with the stated policy. We will need to be
very careful if / when we propose fundamental changes.

Evan
> 
> -eric