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 developer's meeting. The stomach bug that stopped me from getting there wasn't at all nice to look at, so you all lucked out by not catching it from me, I think!> This was done to support arbitrary precision integers in the interpreter > (about the only way to test them). > >Yes, I'd assumed as much.>> I took advantage of the old GenericValue fitting into a 64-bit word, >> since it was fairly obviously intended to be exactly that, with the >> union serving to provide convenient access to various ways that it might >> be formatted. >> > > Right. Unfortunately, there are integers now that don't fit into a > 64-bit word so the integer portion of the union was extracted into a > struct. > >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. :-)>> The new GenericValue seems to have morphed into a struct, >> and looks like it's probably not intended to work in the same way as the >> old GenericValue class. >> > > Right. Correspondingly the interpreter code change a fair bit to deal > with this. > >Yes, I can see that.>> Before I weigh in and start ripping my code to pieces, I thought it >> might be a good idea to post here first. >> > > Good idea. > >Indeed -- if I come across anything else that looks weird I'll mention it here first before breaking everything. Thanks, Sarah
Sarah, On Tue, 2007-07-17 at 11:28 -0700, Sarah Thompson wrote:> 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 developer's meeting. The stomach > bug that stopped me from getting there wasn't at all nice to look at, so > you all lucked out by not catching it from me, I think!Yes! Thank you so much for not showing up and sharing your illness. :) Glad you're feeling better.> > This was done to support arbitrary precision integers in the interpreter > > (about the only way to test them). > > > > > Yes, I'd assumed as much. > >> I took advantage of the old GenericValue fitting into a 64-bit word, > >> since it was fairly obviously intended to be exactly that, with the > >> union serving to provide convenient access to various ways that it might > >> be formatted. > >> > > > > Right. Unfortunately, there are integers now that don't fit into a > > 64-bit word so the integer portion of the union was extracted into a > > struct. > > > > > Do I understand correctly that there is nothing that the current gcc > front end generates that wouldn't fit an old-style GenericValue?Depends on which GCC yo're talking about. In the llvm-gcc-4.0 mirror, that's true (I think). However, there are commercial companies that have customized it to generate integers of any bit width. That work will be contributed back as a branch in llvm-gcc-4.0 once the mirror gets (finally!) hosted on llvm.org as a full llvm-project module. Some day it might even become mainstream and live in the trunk version.> 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.You are, of course, free to do what you want in your own environment. It should be possible to locally revert the 20 or 30 commits that made this change in your local tree. Either that or you could make a branch. Probably there's a better solution. We could talk about it on IRC if you like.> Model checking VHDL and Verilog can come later. :-)Similar things are already implemented in a commercial product. They'd be a tad bit upset if the llvm features in lli that support their product (e.g. GenericValue change) were reverted.> >> The new GenericValue seems to have morphed into a struct, > >> and looks like it's probably not intended to work in the same way as the > >> old GenericValue class. > >> > > > > Right. Correspondingly the interpreter code change a fair bit to deal > > with this. > > > > > Yes, I can see that. > >> Before I weigh in and start ripping my code to pieces, I thought it > >> might be a good idea to post here first. > >> > > > > Good idea. > > > > > Indeed -- if I come across anything else that looks weird I'll mention > it here first before breaking everything.Okay, Reid.> Thanks, > Sarah
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. -Chris -- http://nondot.org/sabre/ http://llvm.org/
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