[PATCH] Break dependencies in large loops containing reductions (LoopVectorize)

[Olivier Sallenave]

In http://reviews.llvm.org/D7514#127076, @hfinkel wrote:

> It seems like, in general, you want a way to measure the latency of some chain of instructions (other than just counting them). This is general problem, and I recommend going after that issue as follow-up work.


Fair enough.

> 2. As noted below, I don't think you're counting the right thing (or at least, you don't seem to be counting what I'd expect). Can you please elaborate?

> 

>   Don't you want to count the number of instructions needed to compute the value being 'added' to the reduction?


Right, or more precisely the number of instructions between each reduction, because even if there are not computing the value being 'added', we need to take them into account when measuring the level of ILP exposed. To compute this number, we divide the number of relevant instruction (integer of floating-point) with the length of the critical path (that is, the longer reduction chain, which is computed via U = *I++).

> This seems like an odd one-off to have here. FMAs are important, granted, but you don't even check if there are FMAs (or things likely to form FMAs) in the loop.


I agree, I should be less sloppy and check that properly :-) Actually I was wondering, in general, is it okay to emulate what the DAG combiner will do later on? I wasn't inclined to do that because it seems like replication of code.. Your suggestion above about measuring the latency of some chain of instructions is probably the right approach.

In http://reviews.llvm.org/D7514#126666, @nadav wrote:

> Following Hal’s suggestion to benchmark this patch is a really good idea.  Do you know how it affects the LLVM test suite?  Are you seeing any gains or regressions?


I'll benchmark some variants of this heuristic and come back to you.

Thanks.


http://reviews.llvm.org/D7514

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/