similar to: [LLVMdev] Proposal to add Bitcode version field to bitcode file wrapper

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

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 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

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

Hi all, Doug Yung started a discussion earlier ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/077227.html) about using the unused "version" field in the bitcode wrapper, and I think there was some misunderstanding. I'd like to clarify the motivation. The reason we want to add the version field is to easily identify "old" bitcode. It is only LLVM version

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 Sep 29, 2010, at 3:12 PM, Bill Wendling wrote: > Chris rewrote the original LLVM bytecode into it's present bitcode form. The newer code is much smaller than the previous form. That would be my guess for why he chose to call it bitcode. Of course, he can say for himself. :-) The format is literally a bitstream, not a bytestream. See this document for more details:

Thanks for the review Rafael! Chris, did you want to take a look at the patch too? Thanks, - Jan On Wed, Oct 10, 2012 at 12:39 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 10 October 2012 15:15, Jan Voung <jvoung at chromium.org> wrote: > > Yes, I had about 133K hits for INST_PHI with a negative value, out of > 136K > > hits of any

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

On Oct 10, 2012, at 5:10 PM, Jan Voung <jvoung at chromium.org> wrote: > Thanks for the review Rafael! > > Chris, did you want to take a look at the patch too? Your most recent patch looks good to me, with a minor change: +++ b/lib/Bitcode/Writer/BitcodeWriter.cpp @@ -33,6 +33,13 @@ using namespace llvm; static cl::opt<bool>

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

Greetings, I am working on a project (unrelated to LLVM) that needed a bytecode-like format. I found Bitcode and it seems to fit the bill really nicely. I am writing an independent implementation of Bitcode in C (I really want to keep my runtime pure C). In the process of doing this, I've discovered a few things I want to ask about. I notice the Bitcode format documentation [0] is

Am 30.09.2010 00:34, schrieb Chris Lattner: > > The format is literally a bitstream, not a bytestream. See this document for more details: > http://llvm.org/docs/BitCodeFormat.html Ah... something I always meant to ask: How does the LLVM infrastructure deal with the added overhead of packing/unpacking a bitstream? Ignore it since modern CPUs can deal with that? Some ingenious

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 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- I am having a weird problem with setting dom0 kernel output to the serial console with Xen 3.0.4-1, below is my grub setting. With this setting if I don''t enter the grub menu and have the default boot to the first image, everything works fine and I can get output/input to the serial console. The problem is when I enter the grub menu and select the image to boot from, if I

Anyone, can you say what was the reason to rename bytecode? I am still interesting in 2010/9/29 Duncan Sands <baldrick at free.fr> Hi Ariel, > As long as I know English the word "bit" is a "small pice", . Why in set of > documentation ir is "bytecode", in other set or llvm source is "bitecode"? > What is the right? Different people call the

Chris rewrote the original LLVM bytecode into it's present bitcode form. The newer code is much smaller than the previous form. That would be my guess for why he chose to call it bitcode. Of course, he can say for himself. :-) -bw On Sep 29, 2010, at 5:15 AM, Ariel Feinerman wrote: > Anyone, > > can you say what was the reason to rename bytecode? I am still interesting in >