similar to: [LLVMdev] For the avoidance of doubt...

On Mon, 30 Jul 2007, Sarah Thompson wrote: > ... can *any* instruction(s) other than load and store cause memory > reads or writes? Functions calls can (transitively), intrinsics can, and the vaarg instruction can (it updates the pointed to list to point to the next argument). -Chris -- http://nondot.org/sabre/ http://llvm.org/

Sarah Thompson wrote: > ... can *any* instruction(s) other than load and store cause memory > reads or writes? Not that I know of, but some intrinsic functions do. > > This is pretty important, because I need to be able to track (at least) > writes, and ideally also reads in order to be able to make > explicit-state model checking work efficiently. I specifically know that

Chris Lattner wrote: > On Mon, 30 Jul 2007, Sarah Thompson wrote: > >> ... can *any* instruction(s) other than load and store cause memory >> reads or writes? >> > > Functions calls can (transitively), This isn't a problem because I'll be picking up those reads and writes as the function executes anyway. > intrinsics can, Would it be feasible to

Hi all, We somewhat recently created/updated element-wise unordered-atomic versions of the memcpy, memmove, and memset memory intrinsics: Memcpy: https://reviews.llvm.org/rL305558 Memmove: https://reviews.llvm.org/rL307796 Memset: https://reviews.llvm.org/rL307854 These intrinsics are semantically similar to the regular versions. The main difference is that the underlying operation is performed

Hi all, I've been quiet for a while, but work on the new model checker has been going pretty well of late. I do have a question for the team, however. I've implemented code that manages multiple stacks, with an ability to version them and roll back and forward between versions so I can implement backtracking and nontrivial search strategies -- this all works. However, I'm

Hi folks, Assuming that I'm writing a pass and that for bizarre reasons I need to programmatically do the equivalent of a C/C++ sizeof on a Value (or a Type, it doesn't matter which really), yielding a result in bytes, what is the known-safe way to do this? I notice that doing something like struct thingy { ... some stuff ... }; ... printf("Size = %d",

Hi Sanjoy, Response/thoughts below... On Aug 19, 2017, at 3:13 PM, Sanjoy Das <sanjoy at playingwithpointers.com<mailto:sanjoy at playingwithpointers.com>> wrote: Hi Daniel, On Thu, Aug 17, 2017 at 8:32 AM, Daniel Neilson via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Cons: One more attribute to check when implementing a pass that

On Tue, 9 Oct 2007, Sarah Thompson wrote: > ideally, I'd like a block that encompasses everything from the function > parameters up to the current top-of-stack including spilled registers. > Is this feasible? Hi Sarah, I'm not sure how much of this is possible. You're guaranteed that each function stack frame is itself contiguous (including spilled regs), but there

I'll almost certainly come along, possibly with one or two other NASA people. I could give a talk on our work using LLVM to support model checking, symbolic execution and static analysis if anyone is interested. Sarah Thompson RSE/6G, NASA Ames >

Hi, As some of you may remember, I'm implementing an LLVM-based model checker. I'm doing something a little odd, in that mostly I'm using the interpreter (currently a hacked version of lli with threads) for most things because I need to hook into lots of stuff that would be difficult to manage otherwise, but I'm also using the jitter for some things that need to be fast

Hi all, I've been quiet for a while, but I'm liable to be less so now that I'm starting on porting our model checker from LLVM 1.8 to 2.0. One thing that is puzzling me somewhat are the changes made to the GenericValue union, which is now a struct. I haven't found any mention of this on the llvm site or in the archives, so it may be that I am the only one who cares about it

Hmm... looks like my LLVM build script only built debug versions of the tools, not release versions. I'm investigating, I didn't change anything that should have caused that. [s] On Apr 28, 2009, at 4:56 PM, Bill Wendling wrote: > On Tue, Apr 28, 2009 at 4:43 PM, Sarah Thompson <sarah at findatlantis.com > > wrote: >> OK, that got much further, but I'm now

(My script does both of those -- the debug build worked (I think), but the release build fails) [s] On Apr 28, 2009, at 5:19 PM, Bill Wendling wrote: > We build debug by default. You will have to add ENABLE_OPTIMIZED=1 on > the "make" command line or --enable-optimized during configuration. > > -bw > > On Tue, Apr 28, 2009 at 5:12 PM, Sarah Thompson <sarah at

Just to give closure here, I eventually gave up, built an Ubuntu 9 VMWare image which uses gcc 4.3.2 by default, installed Eclipse Ganymede and various other tools, then built LLVM 2.5 and my own code. It all ran fine. There is clearly something broken in the CentOS gcc43 package. Definitely one to avoid. [s] On Apr 28, 2009, at 5:40 PM, Sarah Thompson wrote: > (My script does both

Sarah Thompson wrote: > Hi, > > As some of you may remember, I'm implementing an LLVM-based model > checker. I'm doing something a little odd, in that mostly I'm using the > interpreter (currently a hacked version of lli with threads) for most > things because I need to hook into lots of stuff that would be difficult > to manage otherwise, but I'm also

Hi folks, I'm currently extending my model checker to collect coverage information, and as part of this I'm finding a need to get a more friendly version of munged C++ identifiers than the name used by the linker. For example, though internally, something like '_Z7thread1Pv' is fine as an identifier, I'd like to be able to give the user something more readable. Since

Reid Spencer wrote: > Hi Sarah, > > On Tue, 2007-07-17 at 10:05 -0700, Sarah Thompson wrote: > >> Hi all, >> >> I've been quiet for a while, but I'm liable to be less so now that I'm >> starting on porting our model checker from LLVM 1.8 to 2.0. >> > > We missed you! :) > > Yes, apologies again for not making the

Hi Sarah, On Fri, 2007-03-23 at 15:11 -0700, Sarah Thompson wrote: > I'll almost certainly come along, possibly with one or two other NASA > people. Great! If/when you know their names, have them drop me a line here. I'd rather put down names than "Sarah+2". Thanks. > I could give a talk on our work using LLVM to support model > checking, symbolic execution and

On Sun, Mar 15, 2015 at 3:17 PM, Pasi K?rkk?inen <pasik at iki.fi> wrote: > On Thu, Mar 12, 2015 at 10:34:39PM -0400, Nico Kadel-Garcia wrote: >> I'm looking at a CentOS 5 Xen server that I'd really like to put some >> more recent VM's. There are reasons not to touch it at the moment, so >> I can't upgrade it in place today. >> >> Has anyone

Hi all, I'm considering using ocaml for some experiments I want to try -- does the binding currently support reading existing bitcode, or just generating it? I want to try out some program transformation ideas that would probably be rather easier to express in ocaml than C++. Thank you in advance, Sarah Thompson