[llvm] [llvm] Optimize misaligned accesses with early profitable splitting (PR #145168)

Acthinks Yang via llvm-commits llvm-commits at lists.llvm.org
Sun Jun 22 04:09:33 PDT 2025


Acthinks wrote:

> > > > This is a good idea, but I still have the following questions: 1. MMO BaseAlign corresponds to IR Value, and MPI Offset is a constant. In order to obtain the optimal align info, we may need a new base + offset and introduce a new IR Value, which seems inappropriate.
> > > 
> > > 
> > > It's not necessary to introduce a new IR value, it already exists: It's the pointer operand of a constant offset GEP.
> > 
> > 
> > I mean, maybe in some cases it is not possible to directly get the appropriate base value, they may not be optimally aligned, or the offset may be negative.
> 
> If you don't have an appropriately aligned base your current approach will also not help, right? Do you maybe have an example of the situation you're concerned about?
> 
```
%p, align 2
%gep = %p + %i * 4 + 1  ; align 1
%gep2 = %gep + 2
store %v, %gep2, align 1
```

> And the offset stored in MPI is allowed to be negative.

Yes, MPI offset is int64_t, but the following code uses it as uint64_t. I am not sure if it can get the correct value when the offset is negative:
```
inline Align commonAlignment(Align A, uint64_t Offset) {
  return Align(MinAlign(A.value(), Offset));
}

/// getAlign - Return the minimum known alignment in bytes of the
/// actual memory reference.
Align MachineMemOperand::getAlign() const {
  return commonAlignment(getBaseAlign(), getOffset());
}
```


https://github.com/llvm/llvm-project/pull/145168


More information about the llvm-commits mailing list