Quoting Hans-Peter Nilsson : > On Fri, 23 Sep 2011, Joern Rennecke wrote: > >> Quoting "Paulo J. Matos" : >> >> > My addition instruction sets all the flags. So I have: >> >> This is annoying, but can be handled. Been there, done that. >> dse.c needs a small patch, which I intend to submit sometime in the future. > > Could you be persuaded to send it to the list as-is, right now? > > Be sure to mark it work-in-progress, or someone might feel > compelled to review it. :) Attached. The issue with this patch is that we'll have to check if gen_add3_insn might fail on any target, and also we have to identify on which targets it will create an insn that clobbers potentially live hard registers (like a flags register), and make the substitution fail in this case. I.e. if in doubt, keep the dead store with the auto-increment. But not fail for a target that knows what it clobbers in a reload_in_progress / reload_completed add. For Epiphany, the add will be expanded with a clobber of a fake hard register, and this pattern is subject to various peephole2 patterns which usually find a low-cost substitute. The point of clobbering a fake hard register is to avoid having passes like combine creating the pattern with the unresolved flag clobber problem. The unoptimized add expands into a sequentially issued five-instruction in order to save/restore the flags to a temp register, which in turn is saved on the stack. There are peephole2 patterns to use a constant directly rather than loading it into a temp register, to clobber the flags register if it is free, to move the add before an immediately preceding flag-setting instruction, to find a possibility for a dummy post-modify load from / store to the stack (for calculating a stack/frame based address), and to scavenge a temp register to save the flags into without needing to save the temp register.