On Jan 20, 2015, at 12:11 AM, Mike Stump <mikest...@comcast.net> wrote:
> On Jan 19, 2015, at 10:14 AM, Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> > wrote: >> On Jan 19, 2015, at 6:48 PM, Mike Stump <mikest...@comcast.net> wrote: >>> On Jan 19, 2015, at 5:41 AM, Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> >>> wrote: >>>> In A < B < C < A case all A, B and C are normal instructions. It is a >>>> pre-existing condition. When compiling without debug information we have >>>> ready list "A, B, C". When compiling with debug information, we have >>>> ready list "A, B, C, D" where "D" is DEBUG_INSN. Because we now have 4 >>>> elements to sort instead of 3, qsort can choose a different order of >>>> comparison _among_ A, B and C. >>> >>> Not when the uid is mixed in it cannot. :-) >> >> I think you are misunderstanding the issue. > > If all the required elements are mixed into the comparison operator, then > only 1 ordering is possible, it is stable and reliable across machines, and > that ordering is the same as the ordering that you would get of those > instructions if other instructions were present or not, including by not > limited to debug instructions. In such a stable sort, it is not possible > that the comparison order can ever matter, by definition. > > I think you’re saying the ordering relation is screwed. The solution I like, > is to fix it. Trying to hide a broken ordering relation with obscure code > without fixing the underlying problem, strikes me as not the path forward. Yes, the ordering relation is screwed, as you put it. With the number of independent heuristics that rank_for_schedule has to consider there is no other way then to have a "screwed" ordering. I don't think we can afford sacrificing code quality to gain independency from number of elements being sorted. -- Maxim Kuvyrkov www.linaro.org
