Richard Guenther wrote: > On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson <mi...@it.uu.se> wrote: >> Michael Walle writes: >> > >> > Hi, >> > >> > > To confirm that try -fno-tree-ter. >> > >> > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working >> > assembly code: >> > >> > f2: >> > addi sp, sp, -4 >> > sw (sp+4), ra >> > addi r2, r0, 10 >> > calli __ashrsi3 >> > addi r8, r0, 10 >> > scall >> > lw ra, (sp+4) >> > addi sp, sp, 4 >> > b ra >> >> -fno-tree-ter also unbreaks the ARM test case in PR48863 comment #4. > > It's of course only a workaround, not a real fix as nothing prevents > other optimizers from performing the re-scheduling TER does. > > I suggest to amend the documentation for local call-clobbered register > variables to say that the only valid sequence using them is from a > non-inlinable function that contains only direct initializations of the > register variables from constants or parameters. > > Or go one step further and deprecate local register variables alltogether > (they IMHO don't make much sense, and rather the targets should provide > a way to properly constrain asm inputs and outputs).
Strongly oppose. Local register variables are very useful; maybe not on a linux machine but on embedded systems there are situations you cannot do without. You ever counted the constraint alternatives that that would be needed? You'd need different constraints for QI/HI/SI/DI for each register resulting in myriads of register classes increasing register allocation time and dumps would become impossible to read. I once tried it for a target...never again. Besides that, with local register vars the developer can write code that meets his requirements, whereas for constraints you will always have to change the compiler and make existing sources incompatible. If GCC provides such a feature it must work properly and not be sacrifices for this or that optimization. Correct code is always preferred over non-functional code. Johann > > Richard. >
