This is an archive of the discontinued LLVM Phabricator instance.

Consistently use MemoryLocation::UnknownSize to indicate unknown access size
ClosedPublic

Authored by kparzysz on Aug 6 2018, 10:11 AM.

Details

Summary
  1. Change the software pipeliner to use unknown size instead of dropping memory operands. It used to do it before, but MachineInstr::mayAlias did not handle it correctly.
  2. Recognize UnknownSize in MachineInstr::mayAlias.
  3. Print and parse UnknownSize in MIR.

Diff Detail

Repository
rL LLVM

Event Timeline

kparzysz created this revision.Aug 6 2018, 10:11 AM

First: My experience with MachineMemOperands is limited, so feel free to correct me where necessary.

About 1): I was always told that machine memory operands are optional to give additional information to alias analysis or relax atomicity constraints. However I assumed one of the basic rules is that dropping them will not introduce correctness problems. Operations without machine mem operands should be handled as conservatively as possible.

About 2), 3): I'd be fine with that if we have a good use case. But shouldn't we naturally know the size of memory operations in the backend? I can't think of any architecture right now where we wouldn't be able to know the size of a memory operation...

The practical application of this is to indicate aliasing with a given memory object, but without specifying exactly which part of the object is accessed (since it may be unknown). Dropping memory operands altogether will alias the operation with all other objects, so it will be correct, but overly conservative.

MatzeB accepted this revision.Aug 20 2018, 10:22 AM

The practical application of this is to indicate aliasing with a given memory object, but without specifying exactly which part of the object is accessed (since it may be unknown). Dropping memory operands altogether will alias the operation with all other objects, so it will be correct, but overly conservative.

Okay, it sounded to me like you are fixing a correctness problem, but if this is about allowing more information in the mem operands I'm fine with it.

This revision is now accepted and ready to land.Aug 20 2018, 10:22 AM
This revision was automatically updated to reflect the committed changes.