Which way to lower selects on architectures without conditional moves&

Project Infrastructure LLVM Dev List Archives
#1

Hello,

We have the architecture without conditional moves. Which way can we
lower select?

As we know there was the special pass a long time ago, but it was deleted.

commit c3591a0d48ce045bbf5ae0d78a41f3dae4bb99db
Author: Chris Lattner <sabre@nondot.org>

 remove the LowerSelect pass\.  The last client was the old Sparc

backend, which is long dead by now.

 llvm\-svn: 47323

The problem is that if we use this pass we lose some useful special
optimizing cases for selects, e.g. replacing it by min/max.

Does anyone have some experience with such architecture?

We're trying to generate some "if-then-else" on SelectionDAG now.

Could anyone show the way to generate "if-then-else" constructs on
SelectionDAG?

Thanks in advance,

Sergey.

#2

SelectionDAG can’t have control flow. For X86 we match selects on old CPUs or on types that don’t support cmov to pseudo cmov instructions during isel. Those cmov instructions are marked as “UsesCustomInserter” in the InstrInfo td files. X86TargetLowering::EmitInstrWithCustomInserter will then expand those pseudo instructions into control flow by creating new MachineBasicBlocks and branches. Most of that code is in X86TargetLowering::EmitLoweredSelect.

#3

Hi Sergey,

You may also want to look at the MSP430 backend implementation. It also uses Custom Inserters to translate selects into branches. Since it is a simpler backend (meaning less lines of code) it is easier to follow.

You mentioned that you want to optimise some cases of selects. This is normally done for you by the DAGCombine code. However, if your architecture has relatively cheap branches, such ‘optimisations’ might not be always desirable. The trunk MSP430 and the AVR targets are affected by this problem, and I worked on a backend that suffers from that too. For those targets, deciding which selects should not be combined into non-branching sequences is difficult, but there are a few cases that are pretty obvious. If your target gets affected by this, you may be interested in supporting this: http://llvm.1065342.n5.nabble.com/llvm-dev-AVR-MSP430-Code-gen-improvements-for-8-bit-and-16-bit-targets-tc131716.html

John