[LLVMdev] Loads/Stores and MachineMemOperand

Andrew Trick atrick at apple.com
Thu Dec 13 10:00:38 PST 2012

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).


More information about the llvm-dev mailing list