GenericValue changes from 1.8 to 2.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

GenericValue changes from 1.8 to 2.0

Sarah Thompson-2
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: GenericValue changes from 1.8 to 2.0

Reid Spencer-2
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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: GenericValue changes from 1.8 to 2.0

Sarah Thompson-2
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: GenericValue changes from 1.8 to 2.0

Reid Spencer-2
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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: GenericValue changes from 1.8 to 2.0

Chris Lattner
In reply to this post by Sarah Thompson-2
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: GenericValue changes from 1.8 to 2.0

Sarah Thompson-2
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: GenericValue changes from 1.8 to 2.0

Sarah Thompson-3
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]

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: GenericValue changes from 1.8 to 2.0

Reid Spencer-2
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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev