[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