Is there a reason MachineMemOperands are not guaranteed to be persisted in late optimization passes? Is there a use-case where they should be stripped? On Wed, Dec 12, 2012 at 9:50 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:> > On Dec 12, 2012, at 5:50 PM, Justin Holewinski < > justin.holewinski at gmail.com> wrote: > > > Is this documented somewhere? > > It seems that it isn't. It ought to go in the header file. > > /jakob > >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121213/9dbcb888/attachment.html>
On Dec 13, 2012, at 4:43 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote:> Is there a reason MachineMemOperands are not guaranteed to be persisted in late optimization passes? Is there a use-case where they should be stripped?That's not really the issue, though. As an intermediate representation, MI should be reasonably self-contained. The MMOs are pointers into an old version of the program being compiled - The MI representation has undergone many transformations, including CFG changes and code motion. The links provided by the MMOs get more and more sketchy as the program is optimized. Currently, we only use the MMOs for alias analysis during scheduling, but even that can cause problems as you've seen with the stack coloring pass. If you are attaching specific semantics to address spaces, you should encode it in either opcodes or explicit operands. /jakob
On Dec 13, 2012, at 9:03 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:> > On Dec 13, 2012, at 4:43 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > >> Is there a reason MachineMemOperands are not guaranteed to be persisted in late optimization passes? Is there a use-case where they should be stripped? > > That's not really the issue, though. As an intermediate representation, MI should be reasonably self-contained. The MMOs are pointers into an old version of the program being compiled - The MI representation has undergone many transformations, including CFG changes and code motion. The links provided by the MMOs get more and more sketchy as the program is optimized. > > Currently, we only use the MMOs for alias analysis during scheduling, but even that can cause problems as you've seen with the stack coloring pass. > > If you are attaching specific semantics to address spaces, you should encode it in either opcodes or explicit operands.My interpretation: if correct code generation requires the exact address space, they should be directly represented in the instruction (as opcode or explicit operand). It's fine to use the MMO for optimization, such as alias analysis, however important they may be on your target, as long as some conservative fall back exists (e.g. unknown address space aliases with all others). -Andy