[PATCH] D38097: [IVUsers] Changes to make IVUsers's results robust to instruction and uselist ordering

[Daniel Neilson via Phabricator via llvm-commits]

dneilson added a comment.

In https://reviews.llvm.org/D38097#876869, @hfinkel wrote:

> In https://reviews.llvm.org/D38097#876817, @dneilson wrote:
>
> > In https://reviews.llvm.org/D38097#876806, @hfinkel wrote:
> >
> > > Any performance changes in the test suite?
> >
>
>
> You can run LLVM's test suite using LNT by following the directions here: http://llvm.org/docs/lnt/quickstart.html


Thanks for the LNT pointer -- seems like a pretty awesome tool!

I ran the benchmarks in the test-suite (excluding all external source ones, since I don't have them) on a Linux-x86 box, with 5x multisampling. Looks like 2 runtime regressions, and a runtime improvement:
MultiSource/Benchmarks/llubenchmark/llu - 3.56% (3.8200 -> 3.9560, sigma=0.0433). ** REGRESSION **
MultiSource/Benchmarks/TSVC/CrossingThresholds-fit/CrossingThresholds-fit - 1.11% (2.8800 -> 2.9120, sigma 0.0054). **REGRESSION**
SingleSource/Benchmarks/Misc/flops-4 - -5.26% (1.9760 -> 1.8720, sigma 0.0178). ** IMPROVEMENT **

Clearly we'd be missing one or more IVUsers as input to LSR in these benchmarks. It's interesting that it resulted in a 5% improvement in one benchmark. I don't understand LSR at all, and the code looks like a bit of a beast to wrap my head around, so this is going to require a lot more time & digging around to understand why these benchmarks are acting as they are with this patch.

>> Functionally, this patch doesn't regress anything in 'ninja check-all'
> 
> Sounds good (although I have no idea how good our coverage is in this regard).

Yeah, I don't know either. The IVUsers-specific tests are basically non-existent, so we'd pretty much be relying on the LSR tests to catch things.


https://reviews.llvm.org/D38097