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.
