[PATCH] D15730: [MachineLICM] Fix handling of memoperands

Andrew Trick via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 22 21:38:33 PST 2015

atrick added a comment.

Here's my current understanding, but I'm open to other possibilities.

- Empty memoperands should be interpreted as the most conservative state.

- Going from zero to non-zero memoperands would indeed be an error.

- Casual pass writers often forget to propagate memoperands entirely (naïve sloppiness is ok), but dropping only some of them and not all of them would be incorrect (conscious sloppiness is an error).

- addMemOperand is supposed to be an "internal" API, not called directly from passes.

- Merging memory accesses cannot be done naïvely.

- We should work hard to avoid empty memoperands, and to that end we could introduce PseudoSourceValues with specific meanings. I certainly don't think that overflowing memoperands should result in a zero memoperands state, which as Sanjoy pointed out is more error prone.


More information about the llvm-commits mailing list