On Jul 30, 2007, at 2:40 PM, Evan Cheng wrote: > > I appreciate you're trying to think of ways to expand the use of > subreg work. But x86-64 implicit zero-extension is not the same > problem. Trying to solve the x86-64 optimization issue this way is > a unacceptable hack. Your subreg pass is a general pass. Please > keep it that way.
Settled. There are other cases where I think it would be interesting to model implicit operations or more complex register constrains in a way that the register allocator an coalescing has a way to deal with them. For instance, the kind of constraints that cause MOV16to16_ to be necessary. Here I'd think that coalescing could be taught how to coalesce moves between register classes and sub classes of that class. Currently the following MOV16to16_ wouldn't be coalesced, though it could be, because CX is in class GR32_ and AX is in class GR32. CX = mov AX Coalescing would see this as GR32_:reg1025 = mov GR32:reg1024 So it isn't as simple as it may seem at first because you'd potentially have to tighten the register class constraint on the def of reg1024, but I think it's doable... There is an internal architecture here that it would be interesting to target with LLVM, but it happens to have a highly constrained register file, requiring many of these currently un-coalesced moves between register sub classes and their parent. Do you think I should open a PR on that? -- Christopher Lamb _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
