[LLVMdev] ConstantExpr refactoring

[Nick Lewycky]

Renato Golin wrote:
> Hi all,
>
> It's been a long time, and I'm probably going to kill myself, but I
> want to try it anyway.

I don't think that turning off folding of constants is the right place 
to start. To implement this, start by adding new constants that are 
going to replace the existing ones. A good rule of thumb is "whatever 
the relocations in a given object format support", and the start making 
llvm support them. Given that it's driven by object formats, these new 
nodes will only be created by something that has a TargetData object. 
Maybe its API takes an existing instruction to fold, and it may or may 
not produce a constant depending on the target.

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.

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.

Nick

>
> Bug 10368 [1] tells me that ConstantExpr shouldn't automatically fold,
> and that this is source of many problems (most notably with traps) and
> code duplication.
>
> However, I'm a bit lost... There seem to be constant folding in many places like
>
> ConstantExpr::get*() uses
> lib/Analysis/ConstantFolding.cpp, that uses
> lib/VMCore/ConstantFold.cpp
>
> InstCombine also has some instruction simplification (duh), but it
> mostly deal with variables, so it only returns a semantically and
> simpler equivalent operation, rather than go all the way to fold if
> both arguments are constants (I guess).
>
> So, is the idea to transform ConstantFolding into a new function pass,
> or to recode another pass (like InstCombine) to deal with such things?