MachineMemOperands store a MachinePointerInfo (with base value and offset) and a base alignment, where the alignment of the actual memory access is computed from the base alignment and the offset. As such, to correctly determine the alignment of a particular load/store it is important to know both the base alignment and the offset.
However, if the base value is not known, then currently withOffset calls are simple no-ops, so that effectively the alignment ends up being equal to the base alignment. Fortunately this doesn't happen often due to a combination of a) unspecified bases being uncommon and b) a lot of code contains unnecessary redundant MinAlign calls which end up masking the issue. The attached X86 test case is one instance there this did not occur. Previously the store to 15(%rsp) was generating a movaps.
This patch fixes the issue by preserving the offset even if there is no base value.
I'm not sure if this is the right fix -- I was generally left rather confused trying to understand how alignments are treated in codegen. I got the impression that there is a lot of code that's computing alignments and passing them where really a base alignment is expected.
The output here looks a bit odd now, usually if there's a base value and offset this will be printed as load X from XXX + Y. Maybe I should make it print load 8 from unknown + 8 here?