https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116145
--- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to ktkachov from comment #4) > Intersting, thanks for the background. The bigger issue I was seeing was > with a string-matching loop like https://godbolt.org/z/E7b13915E where the > constant pool load is a reasonable codegen decision, but unfortunately every > iteration of the loop reloads the constant which would hurt in a tight inner > loop. > So perhaps my problem is that the constant-pool loads are not being > considered loop invariant, or something is sinking them erroneously Ah, Yeah, that's definitely a bug. It looks like fwprop is pushing the constant vector initialization into an UNSPEC, which LIM doesn't know is invariant so can't pull it out. We also don't do so in GIMPLE because the operation isn't lowered. pc_15 = svmatch_u8 (pg_12, arr1_14, { 63, 92, 13, 10, ... }); so the constant is never removed from the instruction in GIMPLE. Should probably look at whether we really need an UNSPEC there.
