Hi Richard, Thanks for working on this. Comments below.> I don't understand the basis for the last statement though. Do you mean > that you think most cases produce better code if scalarised at the SD stage > rather than at the IR level? Could you give an example?You presented an example that shows that scalarizing vectors allow further optimizations. But I don’t think that this example represents the kind of problems that we run into in general C++ code. We currently consider vector legalization a codegen problem. LLVM is designed this way to handle certain kind of programs. Other users of LLVM (such as OpenCL JITs) do scalarize early in the optimization pipeline because the problem-domain presents lots of vectors that needs to be legalized. I am very supportive of adding the new scalarization pass, but I don’t want you to add it to the PassManagerBuilder because the PMB is designed for static C compilers, that don’t have this problem. Are you interested in improving code generation for c++ programs or for programs from another domain ? Thanks, Nadav -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131114/2a74b959/attachment.html>
Nadav Rotem <nrotem at apple.com> writes:>> I don't understand the basis for the last statement though. Do you mean >> that you think most cases produce better code if scalarised at the SD stage >> rather than at the IR level? Could you give an example? > > You presented an example that shows that scalarizing vectors allow > further optimizations. But I don’t think that this example represents > the kind of problems that we run into in general C++ code. We currently > consider vector legalization a codegen problem. LLVM is designed this > way to handle certain kind of programs.Right. But the reason I wrote the pass in the first place was because treating it as a codegen problem wasn't producing good results. Very little of LLVM gets to see the scalar version in a form that it still understands at the operational level.> Other users of LLVM (such as OpenCL JITs) do scalarize early in the > optimization pipeline because the problem-domain presents lots of > vectors that needs to be legalized. I am very supportive of adding > the new scalarization pass, but I don’t want you to add it to the > PassManagerBuilder because the PMB is designed for static C compilers, > that don’t have this problem.But why do you think static C compilers don't have this problem? The vector extensions to C were added for a reason :-) And you can go quite a long way with generic vector operations.> Are you interested in improving code generation for c++ programs or > for programs from another domain ?Both. Or more precisely: I want vector input to be optimised wherever it comes from. Are you worried that adding it to PMB will increase compile time? The pass exits very early for any target that doesn't opt-in to doing scalarisation at the IR level, without even looking at the function. Thanks, Richard
Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes:> Are you worried that adding it to PMB will increase compile time? > The pass exits very early for any target that doesn't opt-in to doing > scalarisation at the IR level, without even looking at the function.As an alternative, adding Scalarizer and InstCombine passes to SystemZPassConfig::addIRPasses() would probably give me most of the benefit without affecting the PMB. Scalarizer itself would then not test TargetTransformInfo at all, at least in the initial version, and the scalarisation would still logically be done by codegen. Would that be OK? Thanks, Richard