[llvm] [polly] [delinearize] Extract array dimensions from alloca and global declarations (PR #156342)

[Ryotaro Kasuga via llvm-commits]

kasuga-fj wrote:

To be clear: I don't *think* this is a right approach. In that [presentation](https://www.youtube.com/watch?v=gIQEZ3QJz1w), it is explicitly stated that using the type of `alloca` (and probably the same as a global variable) for such a purpose is NOT allowed (assuming I listened and understood the English correctly).

I've long wondered, why are you so particular about array type information? A delinearization function without relying on type information has already been landed (#145050). Isn't it insufficient? It is true that driving the heuristic using type information (which is actually disallowed) can sometimes work better. However, even with the one added in #145050, I believe the basic cases should be covered. In addition, there is room for improvement to catch more cases. In my humble opinion, improving the delienearization without relying on type information would make things go much more smoothly. Or are there specific cases you want to cover that definitely require type information? 
Just in case, the reason I haven’t ported this function to DA is simply that I haven’t had the time since I'm tackling other serious issues in DA.

(This is purely my personal opinion, and I don't have any data, but) even if there were cases that could not be recovered without using type information, I don’t believe that would amount to a critical problem. Such cases tend to be difficult to analyze for dependencies (or a dependence exists in the first place), and even if the dependence analysis works perfectly, I don’t really think it would result in a situation where loop-interchange could be applied (though I don’t know about any other passes that use DA). To summarize, I personally believe that cases where the presence or absence of type information changes whether the optimization is applied are extremely rare. Moreover, what I find most puzzling is that, while there is such great concern for those (I think) rare cases, at the same time [you downplay](https://discourse.llvm.org/t/rfc-de-type-ification-of-llvm-ir-why/88257/26) the numerous potential miscompilations on the grounds that they are "corner cases". In a production-level compiler, miscompilations should be considered far more important than missed optimizations, I believe.

https://github.com/llvm/llvm-project/pull/156342