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

Hi Sean, > Rafael gave me some of the backstory on this. Basically it is to work around some buggy behavior in the Darwin ar. Adding that on the front of the bitcode file just to get a version doesn't seem > like a very clean thing to do. > > Doug, what other alternatives did you guys consider before settling on this? > > As for #2 above, the non-universality of the wrapper

Hi, The conversation has drifted slightly, so I wanted to bring it back to the version field in the bitcode wrapper. Currently in the toolchain which we ship and support, we use a proprietary linker. That linker is unable to read bitcode files and we do not have any plans to enable it to as far as I’m aware. Because of this, we need a way of identifying the version of a bitcode file without

The fundamental problem is that IR has never been treated as "user input" before. It has always been an ephemeral format, and if some component comes along and sees something it doesn't recognize, that is ipso facto a compiler bug, not a user input error, and it's perfectly okay to crash on a compiler bug. Changing that fundamental assumption would be pretty pervasive. I will

On Mon, Nov 24, 2014 at 7:00 PM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > It should report that the > particular new feature is not support. In this case, something like > "unknown 'g' flag in datalayout". > > Currently that would hit an llvm_unreachable(). How should we > re-engineer this to provide sensible error recovery in

On Mon, Nov 24, 2014 at 7:53 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > Right, that version number is used to resolve *ambiguities* in how to > > interpret some chunk of bitcode. It is not a generic bitcode version > > scheme, because most bitcode format changes involve things like adding > > new operands or opcodes, which are easily identified

Where is the testing that proves all this works? Patches welcome… 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. Right now I'm in the middle of un-borking my bots in the wake of the upstream "improvements" to GetSVN.cmake, but

As I understand it, the bitcode compatibility promise doesn't extend as far as debug info metadata (happy to be wrong here!). I think we have a usecase where need to guarantee that debug information from any two arbitrary bitcode files going into an LTO link will result in the expected/correct debug information going into the resulting ELF file; unless we can be sure that this will always

On Tue, Nov 4, 2014 at 2:57 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 4, 2014, at 7:04 AM, Robinson, Paul < > Paul_Robinson at playstation.sony.com> wrote: > > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sean Silva > >> > >> You haven't established that you really need

On Sat, Sep 27, 2014 at 11:35 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > How is this use case different from the LTO-supported toolchains shipped > by other vendors such as Apple? Do they have this theoretical problem too? > > If the issue is solely constrained to debug info metadata, then why not > use metadata to describe the format/version of the debug info? >

On Sun, Oct 5, 2014 at 8:10 PM, Yung, Douglas < douglas_yung at playstation.sony.com> wrote: > Hi – > > > > I realize the thread has drifted a little, but I wanted to get back to my > original proposal. I would like to make a change to the bitcode file > wrapper to include the version of llvm that produced the bitcode. I would > like to write this version into the

Sorry if I was unclear. There are currently no “known incompatibilities” that I am aware of, although I fully admit to not being an expert on the topic. The idea is that we add versioning information to the bitcode so that if an issue were discovered, it could be easily detected and dealt with. Douglas Yung From: Bob Wilson [mailto:bob.wilson at apple.com] Sent: Friday, September 26, 2014 16:39

On Tue, Nov 4, 2014 at 9:10 PM, Bruce Hoult <bruce at hoult.org> wrote: > On Wed, Nov 5, 2014 at 2:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> > Does Apple support library/middleware providers shipping bitcode instead >> >>> > of object code? >>> >>> No. >>> >> >> Are there ever any plans to do so?

Hi, We would like to add a version number to the bitcode wrapper. This feature would allow easier identification of what compiler produced the bitcode so that known incompatibilities with LTO compilation could be detected. Roughly speaking, this version number would consist of the major, minor and optionally the patch version of the compiler used to produce the bitcode. The version information

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sean Silva > > You haven't established that you really need this. AFAIK Apple's linker > doesn't need this version information and they have shipped LTO for a > while now. Does Apple support library/middleware providers shipping bitcode instead of object code? That's the

> Reading the bitcode reader while working on another issues I found > that we already have a version in the bitcode itself (not the darwin > wrapper) and it is used! It is stored with the > bitc::MODULE_CODE_VERSION. It is used to select relative ids, which > impacts the entire bitcode, and so it makes sense to be based on a > version. > > If we ever have a new feature

On Tue Nov 04 2014 at 12:43:05 PM Peter S. Housel <housel at acm.org> wrote: > On 11/04/2014 07:04 AM, Robinson, Paul wrote: > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sean Silva > >> > >> You haven't established that you really need this. AFAIK Apple's linker > >> doesn't need this

On 28 September 2014 23:10, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > | Bitcode backward compatibility, at least for the current major version, is > supposed to make this unnecessary. It didn't use to work that way, and I'm not sure we want it at all. > I think the "at least for the current major version" part is one thing that >

Hi all, Attached is a sequence of patches that changes the IR to support more than two synchronization scopes. This is still a work in progress, and these patches are only meant to start a more detailed discussion on the way forward. One big issue is the absence of any backend that actually makes use of intermediate synchronization scopes. This work is meant to be just one part of the

I've not had a good chance to look at the patches in detail, but just to clarify one point: I don't really care whether we number things going up or down from single threaded to "every thread". I just think it makes sense to expose them in the in-memory IR interface as an enum with a particular ordering so that code can use the obvious sorts of tests for comparing two orderings

Would it make sense for xray instrumentation be part of -fprofile-generate? PGO will affect inlining decisions etc for the optimized binary, but the collected traces during the instrumented build would still have quite a bit of useful information. -- Sean Silva On Mon, Jan 16, 2017 at 4:33 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Google GCC records profile data (dynamic