[LLVMdev] Clarification on the backward compatibility promises

[Philip Reames]

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>