similar to: [LLVMdev] should we stop using llvm-as/llvm-dis in tests?

On Sep 5, 2009, at 1:53 PM, Nick Lewycky wrote: > A recent commit added the ability to opt and llc to read .ll files > directly. Should we go through and update the existing tests? Yes, I think that Dan is planning to do this. -Chris > > llvm-as < %s | opt ... | llvm-dis > > would become: > > opt %s ... -print-module > > and > > llvm-as < %s |

On Sat, Sep 5, 2009 at 5:51 PM, Chris Lattner<clattner at apple.com> wrote: > > On Sep 5, 2009, at 1:53 PM, Nick Lewycky wrote: > >> A recent commit added the ability to opt and llc to read .ll files >> directly. Should we go through and update the existing tests? > > Yes, I think that Dan is planning to do this. ... and it is definitely worth doing. On my system

Daniel Dunbar <daniel at zuster.org> writes: >>> A recent commit added the ability to opt and llc to read .ll files >>> directly. Should we go through and update the existing tests? >> >> Yes, I think that Dan is planning to do this. > > ... and it is definitely worth doing. On my system a 'time' of make > check reports that about 50% of the

This sounds like a good plan. Initially, the tests will be very repetitious, but over time as we make changes they will diverge. For example, before swapping the order of 'alias' and linkage in the IL, we would've had: @a = alias weak i8* @target ; CHECK: @a = alias weak i8* @target This would've been copied to compatibility-3.N.ll for the previous release before the change, and

From the discussion of bitcode backward compatibility on the list, it seems we lack systematic way to test every existing IR features. It is useful to keep a test that exercises all the IR features for the current trunk and we can freeze that test in the form of bitcode for backward compatibility test in the future. I am proposing to implement such a test, which should try to accomplish following

> On Sep 19, 2014, at 9:57 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > So the proposal is that during development new features are added to > test/Features/compatibility.ll (or some other name). When 3.6 is > released, we will > > * assemble the file with llvm-as-3.6. > * Check in the .bc file as test/Features/Input/compatibility-3.6.bc > *

It sounds like the Android RenderScript guys have the most in-the-trenches experience with bitcode incompatibilities. Stephen Hines (CC'd), what sorts of incompatibilities have you guys seen during the 3.x timeline? Would Steven Wu's proposal catch the sorts of incompatibilities that you guys have seen? -- Sean Silva On Thu, Nov 6, 2014 at 4:38 PM, Steven Wu <stevenwu at apple.com>

2017-06-07 10:19 GMT-07:00 David Blaikie <dblaikie at gmail.com>: > > > On Wed, Jun 7, 2017 at 10:01 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> 2017-06-07 9:44 GMT-07:00 David Blaikie <dblaikie at gmail.com>: >> >>> >>> >>> On Tue, Jun 6, 2017 at 2:21 PM Mehdi AMINI <joker.eph at gmail.com> wrote: >>>

2017-06-07 9:44 GMT-07:00 David Blaikie <dblaikie at gmail.com>: > > > On Tue, Jun 6, 2017 at 2:21 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> 2017-06-06 13:38 GMT-07:00 David Blaikie <dblaikie at gmail.com>: >> >>> >>> >>> On Tue, Jun 6, 2017 at 1:26 PM Mehdi AMINI <joker.eph at gmail.com> wrote: >>>

2017-06-05 14:27 GMT-07:00 David Blaikie via llvm-dev < llvm-dev at lists.llvm.org>: > I know there's been a bunch of discussion here already, but I was > wondering if perhaps someone (probably Teresa? Peter?) could: > > 1) summarize the current state > 2) describe the end-goal > 3) describe what steps (& how this patch relates) are planned to get to (2) > >

2017-06-06 13:38 GMT-07:00 David Blaikie <dblaikie at gmail.com>: > > > On Tue, Jun 6, 2017 at 1:26 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> 2017-06-05 14:27 GMT-07:00 David Blaikie via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> I know there's been a bunch of discussion here already, but I was >>> wondering if

On Tue, Jul 15, 2014 at 10:46 AM, John Criswell <jtcriswel at gmail.com> wrote: > On 7/15/14, 9:32 AM, Gaoyao Xiao wrote: > > Hi, > > > I have some IR files which can be compiled using llc-3.0 and gcc-4.6.3. > I want to instrument these IR files. My instrumentation pass is implemented > under LLVM-3.5 and some data structures in LLVM-3.5 are not available on >

On Nov 8, 2012, at 3:31 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Joe, > >> We have a tool which reads in bitcode, processes it, and re-emits it. We use >> this tool as a flexible way to integrate our tool into the Xcode, Android NDK, >> Chromium, and Linux build process. >> >> The problem we face is that bitcode changes, and when it does…

Hi all. I made some early experiments --- namely a llvm program that printf'd "hello world" -- that seemed to indicate that a bitcode file I generate on linux would work on my solaris box. Well, they're actually the same machine, an amd opteron sun box with a linux vm running. My generating program doesn't run on solaris, but I was hoping to generate bitcode for it from

Hi, When I execute the command bellow: $llvm-dis Example.bc -o Example.ll I get the following wrong message: llvm-dis:Bitcode stream should be a multiple of 4 bytes in length Who can help me? 2010-04-07 yiqiuping1986 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100407/2cd7a437/attachment.html>

Hi Joe, > I have made a .s file, which can be correctly assembled > and run with lli. But when I optimize it I get no errors > from the optimizer, but the resultant file is incorrect. > > Here's what happens: > > llvm-as test2_gen.s %% no errors test2_gen.s.bc is produced there's actually no need to assemble this to bitcode: you can pass test2_gen.s directly to

On Nov 8, 2012, at 7:09 AM, Joe Abbey <jabbey at arxan.com> wrote: >>> The problem we face is that bitcode changes, and when it does… future versions >>> can read it, but past versions are left in the lurch. For instance LLVM 3.2svn >>> can BitcodeReader from LLVM 3.1, but LLVM 3.1 can't BitcodeReader LLVM 3.2 >>> (after r165739.) There was an

Going from IR <-> BC does not seem to create a difference. IR -> BC -> IR -> BC, either with clang frontent or by using llvm-as and llvm-dis yields identical bc files. I have only been able to reproduce this issue when emitting to an object file. > On 18 Jan 2019, at 18:09, <paul.robinson at sony.com> <paul.robinson at sony.com> wrote: > > > >>

On Wed, Jun 7, 2017 at 8:58 AM, Charles Saternos <charles.saternos at gmail.com > wrote: > Alright, now it outputs YAML in the following format: > > --- > NamedGlobalValueMap: > X: > - Kind: GlobalVar > Linkage: ExternalLinkage > NotEligibleToImport: false > Live: false > a: > - Kind:

We've noticed a difference in the embedded bitcode when compiling human readable IR to an object directly vs first compiling IR to BC and then an object through clang -cc1. If the original IR file contained an "llvm.compiler.used" gv, it will be preserved when compiling IR -> BC -> Obj. When compiling IR -> Obj directly, it will be removed. This difference does not exist