This is an archive of the discontinued LLVM Phabricator instance.

Target hook to control Switch lowering.
Needs ReviewPublic

Authored by kariddi on Mar 30 2016, 8:28 AM.

Details

Reviewers
hans
Summary

This patch adds a target hook to control the lowering of switch instructions in our default switch lowering pass.

The assumption is that there are certain kinds of switch instructions that can more efficiently lowered by the target because of how the targets handles control-flow.
Certain GPUs for example could lower switch more efficiently in certain cases than using a tree of conditions.

Diff Detail

Repository
rL LLVM

Event Timeline

kariddi updated this revision to Diff 52065.Mar 30 2016, 8:28 AM
kariddi retitled this revision from to Target hook to control Switch lowering..
kariddi updated this object.
kariddi added a reviewer: hans.
kariddi set the repository for this revision to rL LLVM.
kariddi added a subscriber: llvm-commits.
hans edited edge metadata.Mar 30 2016, 8:55 AM

This adds to the confusion about the two different switch lowering implementations.

As far as I can tell, none of the in-tree targets in LLVM use this "default lower switch pass" except AMDGPU. All the others use SelectionDAGBuilder.

For example, on X86 your TargetTransformInfo::shouldLowerSwitch() method would return true, indicating that it wants to use LowerSwitch, except that it doesn't, and that pass isn't even in the pipeline for X86. Pretty confusing.

IIUC, LowerSwitch gets run because StructurizeCFG depends on it. Could you make this dependency optional, and then instead of running LowerSwitch directly in your target, run a custom pass that looks at the switches and either runs LowerSwitch on them or leaves them alone / does something else?

This patch is also missing tests.

Hmm, that is actually a possible interesting approach. Right now processSwitchInst is not callable from outside, the LowerSwitch pass, but maybe we could make it a utility function, like SimplifyCFG.

Otherwise, the original idea of the patch is to give more control to the target about the way switches are lowered.

You are right that the SelectionDAGBuilder lowering wouldn't be addressed by this and I'm wondering if it would actually make sense to add a custom lowering hook in SelectionDAGBuilder to be able to emit a target instruction representing a switch instead of an expansion of branches that would be very difficult to understand we are dealing with a switch and roll it back.

What do you think? I'm not very familiar on how the selectiondagbuilder emits the expansion. It seems to be creating the same kind of tree if jump tables are not available and creates additional basic blocks, so doesn't look easily "rollbackable".

hans added a comment.Mar 30 2016, 3:25 PM

Hmm, that is actually a possible interesting approach. Right now processSwitchInst is not callable from outside, the LowerSwitch pass, but maybe we could make it a utility function, like SimplifyCFG.

I think that might be a good approach. It already lives in lib/Transforms/Utils after all :-)

Otherwise, the original idea of the patch is to give more control to the target about the way switches are lowered.

You are right that the SelectionDAGBuilder lowering wouldn't be addressed by this and I'm wondering if it would actually make sense to add a custom lowering hook in SelectionDAGBuilder to be able to emit a target instruction representing a switch instead of an expansion of branches that would be very difficult to understand we are dealing with a switch and roll it back.

What do you think? I'm not very familiar on how the selectiondagbuilder emits the expansion. It seems to be creating the same kind of tree if jump tables are not available and creates additional basic blocks, so doesn't look easily "rollbackable".

Yes, it would be very hard to roll back what SelectionDAGBuilder does to switches.

Having a hook to allow a custom switch lowering in SelectionDAGBuilder would work, I suppose.