Why does Select have a higher speculation cost than other instructions?

Hi,

The ComputeSpeculationCost() function in
Transforms/Utils/SimplifyCFG.cpp uses a higher speculation cost for
Select than other instructions. Does anyone know why this is?

I would like SimplifyCFG to be able to speculatively execute Select
instructions. Which of these solutions makes the most sense:

1. Change speculation cost of Select from 2 to 1.

2. Add a TargetTransformInfo callback for Select speculation cost.

3. Add a TargetTransformInfo callback for PhiNodeFoldingThreshold to
enable speculation of more expensive instructions.

4. Something else.

Thanks,
Tom

Hi Tom,

FWIW: I think any of the above could be justified given the current situation. Ideally, we shouldn’t use any TTI info in this pass. We should decide on a canonical form for CFG patterns based on facilitating downstream target-independent optimizations passes. We should have a target-specific CFG optimization pass that runs just before codegen and uses the subtarget’s cost model with as many hooks as we want to throw in.

Short of doing this, I can’t claim any of your workarounds makes more sense than the other. It looks like someone didn’t want to form chains of Selects, but I’m not sure why. If you could verify that it doesn’t regress x86, then changing the standard cost is fine with me.

-Andy

From: "Andrew Trick" <atrick@apple.com>
To: "Tom Stellard" <tom@stellard.net>
Cc: llvmdev@cs.uiuc.edu
Sent: Friday, May 30, 2014 2:15:29 PM
Subject: Re: [LLVMdev] Why does Select have a higher speculation cost than other instructions?

> Hi,
>
> The ComputeSpeculationCost() function in
> Transforms/Utils/SimplifyCFG.cpp uses a higher speculation cost for
> Select than other instructions. Does anyone know why this is?
>
> I would like SimplifyCFG to be able to speculatively execute Select
> instructions. Which of these solutions makes the most sense:
>
> 1. Change speculation cost of Select from 2 to 1.
>
> 2. Add a TargetTransformInfo callback for Select speculation cost.
>
> 3. Add a TargetTransformInfo callback for PhiNodeFoldingThreshold
> to
> enable speculation of more expensive instructions.
>
> 4. Something else.

Hi Tom,

FWIW: I think any of the above could be justified given the current
situation. Ideally, we shouldn’t use any TTI info in this pass. We
should decide on a canonical form for CFG patterns based on
facilitating downstream target-independent optimizations passes. We
should have a target-specific CFG optimization pass that runs just
before codegen and uses the subtarget’s cost model with as many
hooks as we want to throw in.

Short of doing this, I can’t claim any of your workarounds makes more
sense than the other. It looks like someone didn’t want to form
chains of Selects, but I’m not sure why. If you could verify that it
doesn’t regress x86, then changing the standard cost is fine with
me.

Tom,

Out of curiosity, did you ever do anything with this?

-Hal