similar to: [LLVMdev] Clarification on the backward compatibility promises

On 17 June 2014 16:07, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hi Rafael, > >> Do others agree that this is the case or at least that this would be a >> reasonable balance? > IMO it's easier to be compatible on .ll level, no? That is not my experience with the bitcode format. The way the API is structured makes it really easy to support backwards

> 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

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

> On Jul 9, 2014, at 9:52 PM, Eric Christopher <echristo at gmail.com> wrote: > > 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: >> >>

Does anyone have anything else to say about .bc/.ll compatibility? It is important to be clear to users about what compatibility we provide. I'd like to get consensus about this and put it in the docs somewhere. -- Sean Silva On Wed, Jun 18, 2014 at 11:15 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, Jun 18, 2014 at 10:35 AM, Tim Northover

On 18 June 2014 17:10, Sean Silva <chisophugis at gmail.com> wrote: >> >> Do others agree that this is the case or at least that this would be a >> >> reasonable balance? >> > IMO it's easier to be compatible on .ll level, no? >> >> That is not my experience with the bitcode format. The way the API is >> structured makes it really easy

On Mon, Apr 27, 2020 at 6:42 AM Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Older releases are still available for download at releases.llvm.org; I > believe the 3.0 release was supposed to be able to read 2.x bitcode, so you > should be able to upgrade the bitcode with 3.0 tools and proceed from > there. I **think** everything since 3.0 is still readable

I admit I didn't know about that, but that is because I am handling a lot of *old* bugs, older than LLVM version 3.0. Version 3.0 has been released in Dec 1st 2011, and there are still many bugs open from before that point. The current BC Reader can't parse files produced by LLVM version 2.9 and below (I've checked). So, I wonder if there is anyone in favor, against (, or just

Quite often I get to work on an old bug, where an old ll/bc file is attached as a testcase. These files, in most cases (if not all), need to be converted somehow to the latest format, for the trunk version to be able to parse it without an error. So a few questions arise: 1. Is there a standard way to convert an old ll/bc to the latest? If not, what is the common approach for these cases? 2.

Hi, I’ve noted some change in wording on the current (4.0) developer policy[1], compared to the 3.9 developer policy[2]. Specifically the part about IR Backwards Compatibility. The change from 3.9 to 4.0 is the following: - The textual format is not backwards compatible. We don’t change it too often, but there are no specific promises. - Additions and changes to the IR should be reflected

Hi all, I am working on adding PGO to LDC (LLVM D Compiler). The current implementation 1) uses LLVM's InstrProf pass to generate an instrumented executable 2) links to compiler-rt/lib/profile for the runtime functionality to write a raw profile data file 3) uses llvm-profdata to merge profile data and convert from profraw to profdata format 4) uses llvm::IndexedInstrProfReader to read-in

On Nov 11, 2012, at 12:44 AM, Chris Lattner wrote: > > On Nov 10, 2012, at 10:43 AM, Joe Abbey <jabbey at arxan.com> wrote: > >> Hello, >> >> Chris's "keynote" at the LLVM Developers' Conference included a call for code owners, and my company has a heavy dependency on Bitcode, I propose taking ownership of: >> >> lib/Bitcode/*

Hello, Vikas > can any one help me a way to back port the solution files to > VisualStudio 6.0 project files. Unfortunately, this is pretty useless: VC6 C++ is deeply broken in order to compile LLVM. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hi all, We branched for the 3.1 release! (Yay!) If there are any fixes which you think should go into the release, please contact the code owners (http://llvm.org/docs/DeveloperPolicy.html#owners) so that they can approve the patches. No patches will be accepted into the 3.1 release without prior approval! This should be a great release! :-) -bw

> On Aug 2, 2016, at 8:49 PM, Stephen Hines <srhines at google.com> wrote: > > > > On Tue, Aug 2, 2016 at 8:44 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Aug 2, 2016, at 8:38 PM, Stephen Hines via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>

Hi James, > Anton Korobenikov is the designated "maintainer", I really-really don't know who said this at first. I'm definitely *not* a maintainer. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

> On Oct 8, 2016, at 10:41 AM, Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Oct 7, 2016 at 11:57 PM Moritz Angermann via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi, > > I’ve noted some change in wording on the current (4.0) developer policy[1], > compared to the 3.9

Hi Justin, There are some backward incompatible features of PTX; for example, special registers are redefined as v4i32 (they were v4i16) in PTX 2.0. And CUDA 4.0 was rolled out last week. I heard that some instructions are deprecated. I am not sure how stable (or unstable) PTX specification is. Do you have a rough assessment of its stability? If PTX specification is still fast evolving, I would

Thanks Steve and Mehdi for the explanation. Steve, I am a little be confused by looking at the code in https://android.googlesource.com/platform/frameworks/compile/libbcc/+/master/bcinfo/BitReader_3_0/BitcodeReader.cpp. Looks like the BitcodeReader do some translation while reading the bitcode. If LLVM ToT can read the bitcode of LLVM 3.0, while can't we just use the bitcode reader in LLVM

On Nov 10, 2012, at 10:43 AM, Joe Abbey <jabbey at arxan.com> wrote: > Hello, > > Chris's "keynote" at the LLVM Developers' Conference included a call for code owners, and my company has a heavy dependency on Bitcode, I propose taking ownership of: > > lib/Bitcode/* > include/Bitcode/* > > This means that I'll be committed to documenting