Duncan Sands <baldrick at free.fr> writes:> there seems to be a plan to get rid of the select instruction and just use > branches and phi nodes instead. Amongst other things this requires boosting > the power of codegen so that branches+phi nodes can be turned into cmov or > whatever when appropriate.This is a very BAD idea. Are you telling me that every predicated instruction will need to be in its own basic block so it can be represented with a phi? Certainly this will be true for any instructions that do not share masks. PLEASE do not do this! This would be a huge step backward in vector support.>> >> It's easy enough to write a TableGen pattern to match add+select and >> emit a masked instruction. Alternative, we can always resort to manual >> lowering (ugh). >> >> For trapping operations this is problematic. Take a load. Here's the >> same attempt with a load: >> >> tt = load [addr] >> t1 = select mask, tt, 0 > > This would not be problematic at the IR level if it was done by branching to > one of two basic blocks based on the condition, and doing the load in the > appropriate basic block. Codegen would however need to become powerful enough > to turn this construct into your target's predicated load.How will that ever happen? isel has never known much about control flow at all. Please do NOT remove select until we have a solid replacement in place, something that's tested and known to work. I cannot object strongly enough. I've bit my tongue at a few IR changes, but not this one. Who propsed this change? Why has it not been discussed on the list? -David
On May 6, 2013, at 9:35 AM, dag at cray.com wrote:>>> It's easy enough to write a TableGen pattern to match add+select and >>> emit a masked instruction. Alternative, we can always resort to manual >>> lowering (ugh). >>> >>> For trapping operations this is problematic. Take a load. Here's the >>> same attempt with a load: >>> >>> tt = load [addr] >>> t1 = select mask, tt, 0 >> >> This would not be problematic at the IR level if it was done by branching to >> one of two basic blocks based on the condition, and doing the load in the >> appropriate basic block. Codegen would however need to become powerful enough >> to turn this construct into your target's predicated load. > > How will that ever happen? isel has never known much about control flow > at all. > > Please do NOT remove select until we have a solid replacement in place, > something that's tested and known to work. > > I cannot object strongly enough. I've bit my tongue at a few IR > changes, but not this one. > > Who propsed this change? Why has it not been discussed on the list?FWIW, I don't think that removing select has ever been really proposed. I would also be pretty against such a thing. That said, there is a question about how much if conversion should happen on IR vs at the machine level. There are interesting design problems to be answered there, but AFAIK, no design would remove select entirely. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130506/26ca9d04/attachment.html>
Chris Lattner <clattner at apple.com> writes:> FWIW, I don't think that removing select has ever been really > proposed. I would also be pretty against such a thing.Whew. Good to know.> That said, there is a question about how much if conversion should > happen on IR vs at the machine level. There are interesting design > problems to be answered there, but AFAIK, no design would remove > select entirely.Ok. Yes, I think there are some interesting design choices in this area. I look forward to a good discussion! -David