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.