On 06/07/2016 09:27 PM, Jan Hubicka wrote: > There are bugs in few predictors - goto predictor is dead because the FE code > was dropped, > return predictor is bit random because CFG is optimized (it should probably > be done in FE), > loop iv compare seems bogus and fortran fail alloc does not seem to work as > intended. > I added FIXME and will addres them incrementally.
Hi. I've just investigated 'fail alloc' predicate which occurs just in 2 SPEC2006 benchmarks: 437.leslie3d HEURISTICS BRANCHES (REL) HITRATE COVERAGE COVERAGE (REL) fail alloc 15 1.3% 100.00% / 100.00% 15 15.00 0.0% and 459.GemsFDTD HEURISTICS BRANCHES (REL) HITRATE COVERAGE COVERAGE (REL) fail alloc 580 12.3% 61.21% / 100.00% 580 580.00 0.0% The first one contains just couple of edges, while Gems contains quite many. As we use the PRED_FORTRAN_FAIL_ALLOC predicate for multiple edges, I've separated the predicate to more to observe what happens: a) It fails in situations where we decorate ALLOCATABLE, which can be called for already allocated object. All such edges have hits == 1. The predicate is set properly. b) Very similar situation in deallocation, where it can be called for a release memory. All such edges have hits == 1. The predicate is set properly. I've also tried polyhedron, where the predicate behaves as follows: HEURISTICS BRANCHES (REL) HITRATE COVERAGE COVERAGE (REL) fail alloc 572 6.0% 66.08% / 100.00% 572 572.00 0.0% The only reason why it fails is array allocation, where the function is called for already allocated array. Thus the predicate should be also fine. It's hard to guess how to properly set the predictor. The name is a bit misleading as it's not tightly connected to a memory allocation failure. As I don't have any real-world fortran code base, it's quite hard to catch some representative numbers. I would alter the number to 70-80%. Thoughts? Martin
