[LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)

[Robinson, Paul]

> -----Original Message-----
> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> Sent: Monday, December 22, 2014 8:12 AM
> To: Robinson, Paul
> Cc: Sean Silva; Bruce Hoult; Yung, Douglas; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Using the unused "version" field in the bitcode
> wrapper (redux)
> 
> > Now, I've known QA people who break software in two minutes as naturally
> as
> > breathing; I do not have that skill.  Given that I came up with
> *anything*
> > in two minutes, I am not filled with confidence.
> 
> We don't have good testing. I agree. As with anything in open source,
> it is just because people had higher priority stuff. I need to fix LTO
> scalability, you were hit by a build system change, etc.
> 
> If this is top priority for some group, what that group could do that
> is aligned with where we want llvm to go is to start adding tests and
> fixing bugs. Fuzzing would be awesome, but even before that, we have
> open bugs on llvm.org/bugs about the bitcode reader crashing that have
> not been fixed because people had more important stuff to work on.
> 
> But note that nothing about the past history of the individual
> development priorities changes the direction we want to go: We want to
> support reading old bitcode format under the limitations described in
> http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility.
> Given the structure of the bitcode, so far it has been possible to do
> so for every change but one without adding a version field.
> 
> And we *have* a version field. If the mentioned above testing finds a
> case that needs a version update, we just need bump
> MODULE_CODE_VERSION again.


I accept that the correct long-term direction is to make the compiler
more robust in this area.  I have, buried on my own to-do list, some
ideas for ways to improve the testing.

It is also the case that *today* the compiler is insufficiently robust
and therefore Sony must use the wrapper as a stop-gap measure to guard 
against those problems until the situation improves (either through our 
efforts or somebody else's).

> And we should most certainly not be making the wrapper mandatory or
> adding feature that apply only to wrapped bitcode files.

I don't think we were suggesting that... certainly the most recent 
proposal made it target-dependent and defaulted to no wrapper, which is
far from "mandatory" and doesn't lend itself to wrapped-only features.

In the meantime it's yet another private change.
--paulr

> 
> Cheers,
> Rafael