[LLVMdev] [cfe-dev] bitwise ops on booleans

[Hal Finkel]

----- Original Message -----
> From: "Sanjay Patel" <spatel at rotateright.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Chandler Carruth" <chandlerc at google.com>, "Clang" <cfe-dev at cs.uiuc.edu>, llvmdev at cs.uiuc.edu,
> joerg at britannica.bec.de
> Sent: Monday, June 29, 2015 6:26:53 PM
> Subject: Re: [LLVMdev] [cfe-dev] bitwise ops on booleans
> 
> 
> ----- Original Message -----
> > From: "Chandler Carruth" < chandlerc at google.com >
> > I don't have any problem teaching codegen to use very specific
> > information to weigh the costs of an additional branch. But that
> > needs to be done in codegen, as it is rare on x86 at this point
> > that
> > a well predicted branch is more expensive than anything, and given
> > the quality of branch predictors on x86, it is also relatively rare
> > that branches are so unpredictable.
> 
> I agree that it's rare, but it's common enough that it makes some of
> our very knowledgeable and perf-starved customers furious when LLVM
> unilaterally declares that it knows best and turns all bit-logic
> into branches.
> 
> At the least, I think this optimization needs a chicken switch

Sure, at least to make benchmarking here easier.

> because there's no way we can know in advance that adding a branch
> will beat a compound predicate in all cases. I attached a test
> program and some results to PR23827. Feedback and more data points
> are certainly appreciated.
> 

If using the bitwise ops are faster sometimes, I think we need a better cost model here. When the expressions don't have side effects, we should use the fastest method regardless of whether & or && was typed. I find it difficult to believe that we cannot come up with a reasonable cost model for evaluating (a && b), branches vs. bitops, if we try.

 -Hal

> 
> Also, we should be careful here: there's no provision for branch
> prediction in the x86 arch. That's purely a micro-arch concept for
> x86 AFAIK. We don't know what micro-arches will look like N years
> from now...even if they're all excellent at prediction today.
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory