I’m adding optional support for a backend for a processor which might not have 8- or 16-bit loads and stores. In my architecture there are only aligned memory accesses.
I’ve managed to make lowering routines which converts the loads into 32-bit load and masks, and lowering of stores into first performing a 32-bit load, and then shifting and masking in the data which is being stored and finally performing a 32-bit store.
However, I’m having problem that after the lowering, the optimizations break the code;
I have multiple 16-bit memory accesses to adjacent 16-bit shorts. Originally the accesses to the different shorts do not alias, so they are not linked to same chains in the selectiondag.
But after I convert those to 32-bit loads and stores, there is aliasing.
LLVM seems to perform an optimization where (after my lowering) it omits a later 32-bit load and uses the result of earlier 32-bit load for the data even there is a 32-bit store to the same address between those. This causes a wrong value being used.
So, when I’m widening the memory accesses from 16 to 32 bits, I should somehow update the chains so that my new 32-bit accesses alias with earlier and later accesses to 16-bit accesses to either of the 16-bit subwords.
Is there an easy way to do it?