[llvm-commits] CVS: llvm/include/llvm/ExecutionEngine/GenericValue.h

[Reid Spencer]

On Sat, 2007-03-03 at 20:11 -0800, Chris Lattner wrote:
> On Mar 3, 2007, at 7:50 PM, Reid Spencer wrote:
> > On Sat, 2007-03-03 at 19:45 -0800, Chris Lattner wrote:
> >>>> Ok, could we make GV not be a union?  Or a struct with an APInt and
> >>>> union of other things?
> >>>
> >>> I thought about that, and started to implement it. That involves  
> >>> a 50%
> >>> increase in memory consumption. Its already a big enough hog.
> >>
> >> It would increase the memory use of the *interpreter*, but nothing
> >> else.  The interpreter is already slow.
> >
> > The JIT makes use of the fields you're intending to delete as well. SO
> > does ExecutionEngine (on each load and store).  Sure you want to
> > sacrifice JIT speed too?
> 
> Yes.  The JIT does not use them for anything performance sensitive.

Well, if there's a lot of global variables, it could delay start up
time.

> 
> >>>>  Having the interpreter have its own set of
> >>>> constant folding logic seems wrong.
> >>>
> >>> Where does it have that?
> >>
> >> All of the 'execute*' methods.  E.g. to 'interpret' a binary or.
> >
> > If its given a ConstantExpr that isn't folded automatically, what's it
> > supposed to do?
> 
> I'm not suggesting that Interpreter::getConstantExprValue change.
> 
> I'm suggesting that things like 'IMPLEMENT_UNSIGNED_BINOP' would drop  
> the
> Int8/Int16/Int32/Int64 cases.

Yes.

> 
> Note that the interpreter is currently broken for sizes like int33.

Oh? I committed patches a few days ago to fix any problems with that.
These are patches that I've had in my tree for over a month while I was
testing the llvm-gcc patch for bitwidth. What did you find?

Actually, it doesn't matter. I'm going to make this change .. have
already started. So far its shrunk Execution.cpp by 500 loc :)

Reid.

> 
> -Chris