Chris Lattner wrote:> On Tue, 17 Jul 2007, Sarah Thompson wrote: > > >> Do I understand correctly that there is nothing that the current gcc >> front end generates that wouldn't fit an old-style GenericValue? I'm >> wondering if this might be an interim approach that would avoid me >> needing to rewrite huge amounts of code, and since we're not likely to >> be supporting anything other than C and C++ in the forseeable future, it >> makes some sense. Model checking VHDL and Verilog can come later. :-) >> > > Right now, the only interesting thing is 128-bit integers. You can get > these on 64-bit targets if you use some funky GCC extensions. Normal code > only produces "usual" sized integers. >OK, in that case I have a 2 phase plan: 1: Refactor my code to use a 'OldGenericValue' class that resembles the pre-2.0 version of GenericValue, and implement conversions as necessary. This will require relatively few changes to my code, so shouldn't be too much of a problem as a first step. This should leave me with a working model checker relatively quickly (and fewer sharp things waved at me by other NASA people who are waiting for it). 2: Refactor the code again to move to the for-real GenericValue class. This is a harder/longer job, but I should at least have a working version of the model checker while I'm working on it. In an ideal world, I'd go straight for 2, but I'm under too much time pressure to go that route unfortunately. None of this should require unusual versions of LLVM or changes to the LLVM codebase. My intention is initially to do this against the 2.0 release, but once that's working (probably concurrently with 2 above) I intend to move to coding against the head branch of LLVM so that my code evolves along with the rest of LLVM. I might be able to give more useful feedback to you lot that way too, of course. Sarah
Sarah Thompson wrote:> Chris Lattner wrote: > >> On Tue, 17 Jul 2007, Sarah Thompson wrote: >> >> >> >>> Do I understand correctly that there is nothing that the current gcc >>> front end generates that wouldn't fit an old-style GenericValue? I'm >>> wondering if this might be an interim approach that would avoid me >>> needing to rewrite huge amounts of code, and since we're not likely to >>> be supporting anything other than C and C++ in the forseeable future, it >>> makes some sense. Model checking VHDL and Verilog can come later. :-) >>> >>> >> Right now, the only interesting thing is 128-bit integers. You can get >> these on 64-bit targets if you use some funky GCC extensions. Normal code >> only produces "usual" sized integers. >> >>Forget everything I said. I looked at the code a bit more, so it looks like I'm just going to have to suck it up and use the new GenericValue class and heavily reengineer the rest of my code. Attempting to use the old GenericValue with new-style bitcode doesn't look all that feasible, and looks like it would need far too much debugging into existence for my liking. Were there any other major structural changes to lli between 1.8 and 2.0, or was that basically the 'big one'? I'm currently thinking I might drop most of my code that was based on the 1.8 sources and basically start again from the 2.0 lli sources. A much bigger job than I'd anticipated, though it would be a lot worse if my backtracking memory implementation hadn't been kept separate. Aaargh, etc. That'll teach me not to develop against the head branch... [s]
On Tue, 2007-07-17 at 18:24 -0700, Sarah Thompson wrote:> Were there any other major structural changes to lli between 1.8 and > 2.0, or was that basically the 'big one'? I'm currently thinking I might > drop most of my code that was based on the 1.8 sources and basically > start again from the 2.0 lli sources. A much bigger job than I'd > anticipated, though it would be a lot worse if my backtracking memory > implementation hadn't been kept separate.You could look at the changes yourself by reviewing the commit logs on the various files, but a quick recap: * lli has the same basic architecture * it now supports arbitrary bitwidth integers, thus the GenericValue change * it works with the changed instructions in 1.9 and 2.0 (see LangRef.html) * some big ugly macros in Execution.cpp were reduced and the code revised to make it easier to follow * There are some new debug features for printing the instructions while executing. * Some bugs were fixed in scanf and fscanf support and GEP handling * There were several changes to accommodate other things in the IR like elimination of static constructions, VMCore interface changes, etc. * IntrinsicLowering mechanisms were changed slightly. I also suggest you read the release notes for the releases and status updates since 1.8 to get some context on the overall changes to LLVM. Reid.> > Aaargh, etc. That'll teach me not to develop against the head branch...Developing against the trunk is fun :) Reid.> > [s] > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev