[LLVMdev] GenericValue changes from 1.8 to 2.0

[Reid Spencer]

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