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 (I think it only really appears in the non-jitted interpreter code, which was the basis of the inner loop of our model checker). 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. 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. Before I weigh in and start ripping my code to pieces, I thought it might be a good idea to post here first. Any light that can be shed on this would be gratefully appreciated. Best regards, Sarah Thompson, RSE Group, NASA Ames Research Center
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! :)> 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 (I think it only really appears in the non-jitted > interpreter code, which was the basis of the inner loop of our model > checker).This was done to support arbitrary precision integers in the interpreter (about the only way to test them).> 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.> 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.> 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.> Any light that can be shed on this would be gratefully appreciated.Hopefully the above is sufficient, if not feel free to ask. Reid.> > Best regards, > Sarah Thompson, > RSE Group, NASA Ames Research Center > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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