On 20/07/15 20:22, Sebastian Pop wrote:
Tom de Vries wrote:
graphite dependence analysis is too slow to be enabled unconditionally.
(read: hours in some simple cases - see bugzilla)
Haha, "cool"! ;-)
Maybe it is still reasonable to use graphite to analyze the code inside
OpenACC kernels regions -- maybe such code can reasonably be expected to
not have the properties that make its analysis lengthy? So, Tom, could
you please identify and check such PRs, to get an understanding of what
these properties are?
Like the one in PR62113 or 53852 or 59121.
PR62113 and PR59121 do not reproduce for me on trunk.
PR53852 does reproduce for me (to the point that I had to reset my laptop).
ISL has a way to count the number of operations, based on a watermark it will
output an error code that we can use to leave graphite: see documentation of
isl_ctx_set_max_operations(). With that mechanism we can set a goal for
graphite of at max (say 10% overhead) of whole compilation time.
Agree, bounding graphite to a limited runtime sound like a good idea.
Determining the bound (in terms of isl operations) doesn't look trivial
though. I suppose a basic version could be number of gimple operations
in function times a constant.
Thanks,
- Tom
