On Jul 30, 2007, at 3:10 PM, Christopher Lamb wrote: > > 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.
Certainly! > 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. Right. > 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... It isn't particularly difficult to teach the coalescer to coalesce across different register classes. The difficult part is figuring out when it is profitable. We have tried to enable coalescing of instructions like MOV16to16_. But in some cases it end up hurting performance because the resultant live interval is longer and have fewer candidate registers for the allocator to target. I think the answer is we must have a way to undo harmful coalescing decision. That is, live range splitting. Without the ability to undo, we shouldn't be any more aggressive about coalescing as we already are. > > 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? Yes, please open an enhancement request and add your ideas. Thanks! Evan > > -- > Christopher Lamb > > > > _______________________________________________ > llvm-commits mailing list > llvm-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
