Maxim Kuvyrkov wrote: > What the heck, I'll jump in as well.
Why not - how many engineers does it take to sort?!? > I'm still working on analysis, but it appears to me that Alexander's patch > (current state of trunk) fails qsort check due to not being symmetric for > load/store analysis (write == 0 or write == 1) in comparisons with > "irrelevant" > instructions. Wilco's patch does not seem to address that, and, possibly, > makes the failure latent (I may be wrong here, it's late and I didn't finish > analysis yet). > > I'm currently bootstrapping the following patch (on aarch64-linux-gnu, > arm-linux-gnueabihf will follow tomorrow), which (like Wilco's patch) seems > to unbreak bootstrap, but is less invasive and preserves handling of > multi_mem_insns. Would please interested parties help me test it? So what you're saying is that if we compare a load with a store (or a store with a load), we should always return 0 and use the original instruction order? This won't fix the issue of overlaps in autopref_rank_data, but I believe this creates a new sorting order problem: A. Load off 8 B. Store off 12 C. Load off 4 So A < B (instruction order), B < C (instruction order) but A > C (offset order)... The key here is that sorting functions should only return zero if the two objects being compared are really indistinguishable, not as a way to say they are not comparable(!!!) and then defer to a different comparison order. It is impossible to combine multiple different comparisons to create a total sorting order that way. However it is feasible to divide things into several classes, order the classes with respect to each other and use a different sort within each class. If you want to treat loads/stores equally, that's fine, but then they end up in the same class and thus you have to use a comparison that orders both loads and stores. Wilco
