On 8/20/24 5:41 AM, Richard Biener wrote:
So the store-merging variant IIRC tracks a single overall source
only (unless it was extended and I missed that) and operates at
a byte granularity. I did want to extend it to support vector shuffles
at one point (with two sources then), but didn't get to it. The
current implementation manages to be quite efficient - mainly due
to the restriction to a single source I guess.
How does that compare to the symbolic execution engine?
What can the symbolic execution engine handle? The store-merging
machinery can only handle plain copies, can the symbolic
execution engine tell that for example bits 3-7 are bits 1-5 from A
plus constant 9 with appropriately truncated result?
Conceptually this is the kind of thing it's supposed to handle, but
there may be implementation details that are missing for the case you want.
More importantly, the execution engine has a limited set of expressions
it knows how to evaluate, so there's a reasonable chance if you feed it
something more general than what is typically seen in a CRC loop that
it's going to give up because it doesn't know how to handle more than
just a few operators.
Note we should always have an eye on compile-time complexity,
GCC does get used on multi-megabyte machine-generated sources
that tend to look very uniform - variants with loops and bit operations
supported by symbolic execution would not catch me in surprise.
Which is why it's a two phase recognition. It uses simple tests to
filter out the vast majority of loops, leaving just a few that have a
good chance of being a CRC for the more expensive verification step
using the symbolic execution engine.
jeff
