[LLVMdev] Clarification on the backward compatibility promises

[Eric Christopher]

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