[LLVMdev] ConstantExpr refactoring

[Renato Golin]

On 1 July 2012 01:35, Nick Lewycky <nicholas at mxc.ca> wrote:
> I don't think that turning off folding of constants is the right place to
> start.

Me neither!

> To implement this, start by adding new constants that are going to
> replace the existing ones.

Adding what, where? I can't add a new ConstantInt if the old one is
still there. If the new unfolding Int gets used, it'll change the
behaviour.


> Or start snipping off individual ConstantExpr nodes. Go through all of llvm
> and remove "shufflevector" constant expression, make sure it's never formed.
> Anyone who tries to constant fold it should use the new methods you created
> in my previous paragraph, and it should only return NULL and stay as
> instructions or produce a new constant vector, but no shufflevector
> ConstantExpr. Insert/Extract element/value are next, then possible select or
> fcmp. Eventually we'll get down to things like "subtract" and that should be
> a target specific node, as I don't think all .o formats can actually
> implement that.

That's another approach, and one that could be more feasible. Instead
of backing up the folding with the pass, I could just turn off each
one individually and deal with one problem at a time.

That'll take a long time, but I guess it's the best option...


> One other request that isn't in the PR, I'd like whatever replaces GEP to
> not store "i32 0" vs. "i64 0". Right now "i8* getelementptr ([1 x i8]*
> @glbl), i32 0, i32 0" is different from "i8* getelement ([1 x i8]* @glbl),
> i33 0, i33 0", and there's an infinite number of these. We should
> canonicalize these harder and only produce one Value* here.

That's kinda silly, I agree. Maybe I should start with this one, which
seams simpler, than later tackle the rest.

After I finish it, we could make a list of the most painful ones, so I
can start with them.

-- 
cheers,
--renato

http://systemcall.org/