Richard Sandiford wrote: > "Steven Bosscher" <[EMAIL PROTECTED]> writes: > >> For the location of the extra instructions, I would *not* keep them on >> the side. If you have something special going on, my motto is: "Make >> it explicit". >> > > Going back to something discussed upthread: would you expect to use this > for hard regs as well as pseudos? No-op moves aren't necessarily supported > for all hard registers. E.g. MIPS doesn't have patterns for LO <- LO, > even though LO is a normal non-fixed register. You can also have hard > registers that only appear in fixed patterns, such as condition code REGs. > > If we went for an explicit move, I assume we would either have to > (a) discount hard regs that can't be moved, (b) force backends to > allow all no-op moves or (c) circumvent the backend somehow. > (Jan suggested a USE for (c), but I assume we'd want some sort > of definition too.) > > Kenny said that pseudos-only was better than nothing, and I can't > disagree with that. But one of the nice things about the on-the-side > idea is that you have none of these problems. There should be nothing > special about hard regs. > > I take your point about not wanting something special going on behind > the scenes. But these insns seem pretty special in their own right, > especially if we go for (a) or (c). Even if we go for (b), wouldn't > optimisers need to know that they shouldn't just delete the moves? > > Richard > This is the first concrete argument that i have seen for keeping them on the side. The rest of the discussions (including my own) have been mostly beauty as opposed to truth.
>From my point of view, this is a killer argument that if we want to build fuds/birthpoints for all regs, the info must be on the side. I want to build the info for everything because i want to ditch the reaching defs way of building chains in favor of building them using the existing ssa technology. I do not want to have to call both techniques to build the chains. kenny
