Hello, On Tue, 2012-11-13 at 09:01 +0000, HEITZMANN Frédéric 218168 wrote: > Hi all, > > I have been working on a MIPS-based platform, which incidently fails to read and write 8bit or 16bit integers, due to a very annoying HW bug. > In other words, any assembly instruction like lb, lbu, sb, lh ... turns to be a no-op. > > A proper manual workaround is to rely on 32bits accesses with proper bit masks, but : > * I do not want to patch any existing code using char or short. > * I want to prevent gcc from optimizing code chunks like this one : > int i = (*(int*)0x1234) & 0xFF; > into > lb r0, 0x1237 > (which it actually does, with -O2 or -Os). > > I would like to tell gcc not to use lb, lbu ... but lw and sw with proper bit masks. > Incidently, I would like to optimize memory accesses when it is possible, e.g. > char* a = (char*)0x1234; > char c1 = *a; > char c2 = *(a+1); > should generate only one read at 0x1234 > > => Is it achievable by changing mips.md ? Yes, it is, although it might not be so easy. > => If so, could someone give me a hint on how to do it ? > => If not, where should I have a look ? QImode and HImode memory accesses are usually expanded through the standard name patterns 'movqi' and 'movhi'. I'm not familiar with the MIPS backend, but the problematic memory access instructions can be emitted during various stages of the compilation (e.g. initial RTL expansion, during combine, during subreg lowering, during reload, after reload etc). You could try to just disable the movqi and movhi patterns and see where it goes, as a start. If that doesn't work or causes too many troubles, you can try to emulate the movqi and movhi patterns at RTL level by splitting the patterns into the desired access instruction sequences. Cheers, Oleg
