This patch introduces the field ExpressionSize in SCEV. This field is calculated only once on SCEV creation,
and it represents the complexity of this SCEV from arithmetical point of view (not from the point of the number
of actual different SCEV nodes that are used in the expression). Roughly saying, it is the number of operands
and operations symbols when we print this SCEV.
A formal definition is following: if SCEV X has operands Op1, Op2, ..., OpN, then
Size(X) = 1 + Size(Op1) + Size(Op2) + ... + Size(OpN)
here N can also be zero if X is a constant or SCEVUnknown.
Expression size may be used as a universal way to limit SCEV transformations for huge SCEVs. Currently,
we have a bunch of options that represents various limits (such as recursion depth limit) that may not
make any sense from the point of view of a LLVM users who is not familiar with SCEV internals, and all
these different options pursue one goal. A more general rule that may potentially allow us to get rid of
this redundancy in options is "do not make transformations with SCEVs of huge size". It can apply to all
SCEV traversals and transformations that may need to visit a SCEV node more than once, hence they are
prone to combinatorial explosions.
This patch only introduces SCEV sizes calculation as NFC, its utilization will be introduced in follow-up patches.
Field alignment nit pick: If you keep it as a full 32 bit field, move it above the two 16 bit fields. With the current layout, you end up as:
128 bit FastId
16 bit SCEVType
16 bit alignment padding
your 32 bit field
16 bit SubclassData
tail padding
i.e. you're burning 32 bits of alignment padding.