search for: legalizevector

...ons; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) +++ lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) @@ -0,0 +1,243 @@ +//===-- LegalizeVectorOps.cpp - Implement SelectionDAG::LegalizeVectors ---==...

...n DAGISelEmitter.cpp. This suggests to me that there is work being done. Are there other similar efforts, but perhaps aiming for bigger gains, that I should be aware of? From the other end, are there efforts to make the fast-path produce better quality code? Some small things I've noticed: - LegalizeVectors might not make a single change over an entire input bc file, yet it can take about 6% of the ISel time. Identifying that this can be skipped ahead of time may help? - We can take the Changed flag returned by LegalizeVectors, and pass it on to Legalize so that it can decide not to AssignTopologica...

...ith this patch, but does > the approach look sane? New version with a few minor changes and fixed-up comments; the previous version had some comments with inaccurate statements, which might be confusing for reviewing. -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) +++ lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) @@ -0,0 +1,239 @@ +//===-- LegalizeVectorOps.cpp - Implement SelectionDAG::LegalizeVectors ---==...

...ing the simplification of > LegalizeDAG and the fixes for UINT_TO_FP and FP_TO_UINT on x86. It > passes regression tests except for one failure due to a missing > implementation of legalization for EXTRACT_SUBVECTOR where both types > are legal. Should it be named something other than LegalizeVectors then, since it handles more than just vectors? Perhaps something like LegalizeOpsNeedingNewTypes? I haven't looked into details, but I think the approach in the patch looks reasonable. Adding yet another pass is somewhat undesirable, though it's better than having two type legalizers, and...

...=================================================================== --- include/llvm/CodeGen/SelectionDAG.h (revision 72159) +++ include/llvm/CodeGen/SelectionDAG.h (working copy) @@ -220,6 +220,13 @@ /// the graph. void Legalize(bool TypesNeedLegalizing, CodeGenOpt::Level OptLevel); + /// LegalizeVectors - This transforms the SelectionDAG into a SelectionDAG + /// that only uses vector operations supported by the target. + /// + /// Note that this is an involved process that may invalidate pointers into + /// the graph. + bool LegalizeVectors(); + /// RemoveDeadNodes - This method deletes...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant