> 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%.
Either that or we can drop the predictor. It was added by me and I obviuosly got confused here. If it is common for function to fail becuase things are already allocated, I think we could just leave it unpredicted and do whatever the generic code does here. Thanks for investigating this! Honza > > Thoughts? > > Martin
