llvm dev - May 2014 - [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.

Thanks,
Tom

On May 28, 2014, at 11:52 AM, Tom Stellard <tom at stellard.net> wrote:
> 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.

-Andy

----- Original Message -----
> From: "Andrew Trick" <atrick at apple.com>
> To: "Tom Stellard" <tom at stellard.net>
> Cc: llvmdev at 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?
> 
> 
> On May 28, 2014, at 11:52 AM, Tom Stellard <tom at stellard.net>
wrote:
> 
> > 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
> 
> -Andy
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory