[llvm-dev] Loop identification

[Krzysztof Parzyszek via llvm-dev]

On 1/13/2017 10:52 AM, Hal Finkel wrote:
> On 01/13/2017 10:19 AM, Krzysztof Parzyszek via llvm-dev wrote:
>>
>> If LLVM supported adding such target-specific passes at that point in
>> the optimization pipeline, you could just write your own pass and plug
>> it in there.
>
> This certainly seems like a reasonable thing to support, but the
> question is: Why should your pass run early in the mid-level optimizer
> (i.e. in the part of the pipeline we generally consider
> canonicalization) instead of as an early IR pass in the backend? Adding
> IR-level passes early in the backend is well supported. There are plenty
> of potential answers here for why earlier is better (e.g. affecting
> inlining decisions, idioms might be significantly more difficult to
> recognize after vectorization, etc.) but I think we need to discuss the
> use case.

The reason is that the idiom code may end up looking different each time 
one of the preceding optimization is changed.  Also, some of the 
optimizations (instruction combiner, for example) have a tendency to 
greatly obfuscate the code, making it really hard to extract useful data 
from the idiom code. It is not always enough to simply recognize a 
pattern, but to replace it with an intrinsic some additional parameters 
may need to be obtained from the initial code. When the code is mangled 
by the combiner, this process may be a lot harder.  Also, combiner is 
one of those things that change quite often.  For recognizing loop 
idioms, the loop optimizations may be the main problem.  The idiom code 
may end up getting unrolled, rotated, or otherwise rendered unrecognizable.


-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation