On Jan 26, 2007, at 6:09 AM, Lauro Ramos Venancio wrote: > Hi Evan, > > Tanks for your review. > >> 1. I think rather than adding a constraint that says a source operand >> must not be assigned the same register as another. It would be better >> if you add a constraint that says a source operand "can be killed at >> issue cycle + n". The live range analysis current assumes every >> source operand read is completed at issue cycle + 0 and write back >> happens at issue cycle + 2. By changing the read latency to 2 you can >> force a source operand to conflict with a destination operand. > > Currently, kill moment of a temporary is determined by the last use of > it. With the constraint proposed by you, an intermediary use could > determine kill moment of a temporary. For example, in an use (with > read latency 5) of a temporary followed by other use of it (with read > latency 0), the kill moment would be determined by first use. This > would complicate liveness algorithm. Does any backend need this > constraint?
The facility does that have to be that general. There are 4 cycles between every two instructions. See LiveIntervalAnalysis: struct InstrSlots { enum { LOAD = 0, USE = 1, DEF = 2, STORE = 3, NUM = 4 }; }; We can restrict the constraint range to 1 - 3. This ensures the last use is always the kill while retaining its flexibility. Evan > > Maybe, it would be better a constraint that changes the kill moment > from default (can kill at issue cycle + 0) to "can kill after > instruction execution". What do you think? > > Lauro _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits