kmclaughlin added a comment.

Thanks all for the suggestions on this patch :)

I had a look at the LowerSwitch pass as suggested by @junparser, and I did find 
that running it before vectorisation transforms the switch and allows the same 
loops to be vectorised. However, I did find that if the loop is not vectorised 
then the switch is not created again later by SimplifyCFG (possibly because the 
pass is also arbitrarily splitting cases into ranges and creating multiple 
branches to the default block?). Tests such as 
Transforms/PhaseOrdering/X86/simplifycfg-late.ll then fail, which attempts to 
convert a switch statement into a lookup table.

For example, running the @switch_no_vectorize test (from remove-switches.ll) 
with -lowerswitch results in:

  for.body:                                         ; preds = %L3, %entry
    %i = phi i64 [ %inc, %L3 ], [ 0, %entry ]
    %sum.033 = phi float [ %conv20, %L3 ], [ 2.000000e+00, %entry ]
    %arrayidx = getelementptr inbounds i32, i32* %a, i64 %i
    %0 = load i32, i32* %arrayidx, align 4
    br label %NodeBlock
  
  NodeBlock:                                        ; preds = %for.body
    %Pivot = icmp slt i32 %0, 3
    br i1 %Pivot, label %LeafBlock, label %LeafBlock1
  
  LeafBlock1:                                       ; preds = %NodeBlock
    %SwitchLeaf2 = icmp eq i32 %0, 3
    br i1 %SwitchLeaf2, label %L3, label %NewDefault
  
  LeafBlock:                                        ; preds = %NodeBlock
    %SwitchLeaf = icmp eq i32 %0, 2
    br i1 %SwitchLeaf, label %L2, label %NewDefault
  
  NewDefault:                                       ; preds = %LeafBlock1, 
%LeafBlock
    br label %L1

I also found that any weights assigned to the switch statement are ignored when 
creating the new branches in LowerSwitch.

I'm not sure what the best approach to this is - I could try to change 
LowerSwitch to create branches which SimplifyCFG will be able to recognise and 
replace with a switch, or try to change SimplifyCFG to recognise this pattern 
of compares & branches. Alternatively, the changes in this patch could be used 
as the basis for a new pass which runs before the vectoriser. I wondered if 
anyone has any thoughts or preferences on which would be the best option here?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108138/new/

https://reviews.llvm.org/D108138

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to