{"push_id":1137673940,"size":2,"distinct_size":1,"ref":"refs/heads/master","head":"33863511b29f4a5feb7d7c809e8a99f14656a4d5","before":"ba03abfbd9ae5792024c09b917dbb3a4d2383939","commits":[{"sha":"882ac67d2a47a2779a495002ada31b22156dfbcf","author":{"name":"Andrew Adams","email":"bc4f2223bb5dc327e4e36cb9d5e85f7d402288a6@gmail.com"},"message":"Defer likely heuristic until loop partitioning\n\nWe have a heuristic in ScheduleFunctions that decides whether or not to\napply a likely on the base for the ShiftInwards tail strategy. This is\nto trade off code size vs performance. It was pretty broken in a bunch\nof cases. The basic problem is that you can't tell at that point what's\ngoing to be an innermost loop. This PR defers the decision until loop\npartitioning time, which is after vectorization and unrolling. This\nunfortunately required a new variant of likely.\n\nlikely always partitions a loop\n\nlikely_if_innermost converts to likely if it's in an innermost loop\n(after vectorization and unrolling). Otherwise it just goes away.\n\nNote that this doesn't necessarily mean we'll partition the innermost\nloop. This would be bad, e.g. if it's a small loop over a convolution\nkernel inside a large loop over pixels. We still partition the outermost\nloop we can that simplifies the likely intrinsics. We just only care\nabout simplifying likely_if_innermost intrinsics if we find them in an\ninnermost loop.","distinct":false,"url":"https://api.github.com/repos/halide/Halide/commits/882ac67d2a47a2779a495002ada31b22156dfbcf"},{"sha":"33863511b29f4a5feb7d7c809e8a99f14656a4d5","author":{"name":"Andrew Adams","email":"bc4f2223bb5dc327e4e36cb9d5e85f7d402288a6@gmail.com"},"message":"Merge pull request #1255 from halide/likely_if_innermost\n\nDefer inject-likely on shiftinwards heuristic until loop partitioning","distinct":true,"url":"https://api.github.com/repos/halide/Halide/commits/33863511b29f4a5feb7d7c809e8a99f14656a4d5"}]}
{"actor":{"display_login":"abadams"}}