[PATCH] D29211: InferAddressSpaces: Support memory intrinsics
Justin Lebar via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jan 27 13:05:32 PST 2017
jlebar added inline comments.
================
Comment at: lib/Transforms/Scalar/InferAddressSpaces.cpp:669
+
+ // Intrinsic users may see the same pointer operand in multiple
+ // operands. Skip to the next instruction.
----------------
arsenm wrote:
> jlebar wrote:
> > It's not just intrinsic users, right? Regular Instructions could have the same problem?
> >
> > How would you feel if we restructured this to be
> >
> > Use &U = *I;
> > ++I;
> > while (I != E && I->getUser() == CurUser) ++I;
> >
> > if (updateSimplePtrUse(U) || updateMemIntrinsicUse(U))
> > continue;
> >
> > ...
> >
> > This seems to be a consistent level of abstraction, instead of having one function which does an update and the other which just does a check and leaves the update to the caller. And it's also obvious how to extend this code to handle other cases -- just add a new `updateFoo` function to the if statement.
> My definition of "SimplePtrUse" was that it has a single pointer operand that can be trivially replaced, so this was specifically avoiding that problem and treating multi users as the complex case. My patches for icmp/select have that problem, and they are handled separately from updateSimplePtrUse
I understand, but there's no harm in running the loop even in this case, right?
It just seems to me much simpler conceptually to say:
- first advance the `I` iterator as needed.
- then muck with the instructions.
https://reviews.llvm.org/D29211
More information about the llvm-commits
mailing list