On Jun 19, 2007, at 8:06 AM, Chris Lattner wrote: >>> This achieves two things: >>> >>> 1. Just looking at the .td file, you can tell which instructions are >>> candidates for remat. >>> 2. The isRematerializable predicate is faster for instructions that >>> are not remat-able. >>> 3. The isReallyRematerializable only needs to be implemented by >>> targets with instructions that are remat-able only in some cases >>> (like the x86 instructions). >> >> I okay'd Dan patch after considering the trade-offs. To me this gets >> rid of the duplicate instructions so it's worth it. > > I think both approaches get rid of the duplicate instructions.
Right, not disputing that. > >> If we are really concerned about the speed, then I agree the hybrid >> approach is the best. Sorry about the confusion. > > Speed is something to consider, but I don't think it should override > maintainability. > >> Not to mention I had already considered the "trivial >> rematerialization" >> scheme to be temporary. > > Okay, how do you think this should work going forward? Trivial remat will go away when proper remat is implemented. All instructions without side-effect will be rematerializable if their operands are available so all these will go away. Not that proper remat is coming anytime soon though. Evan > > -Chris > > > > _______________________________________________ > 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
