tblah wrote: Weighing in with my personal opinion here: - If this can be shown to miss compile any known application then that's grounds for imediately disabling the pass until it can be fixed. - If this only breaks some very obscure fortran formulation that it is unlikely for a human to write then I guess we should weigh up pros and cons. I would lean towards a revert but there have been exceptions made in the past for critical optimisations which are not known to break on any known production code (the example I'm thinking of was a theoretical correctness issue with the TBAA alias tags when a function is inlined into itself which we were confident didn't effect real code because classic Flang had the same issue). - If this is unlikely to be triggered from any fortran code and the pass is providing a noticeable speedup such that disabling it would constitute a measurable regression in Flang codegen then we may decide not to disable the pass, especially if DA is going to be fixed relatively soon.
In this particular case, the pass has been merged for a long time. In that time we have built a lot of applications and benchmarks at -O3 in our internal CI and not seen any issues known to arise from loop interchange. Presumably other organisations have been testing Flang during this time too. @kasuga-fj thank you very much for reporting this. It is helpful for the whole community to know that there could be issues here so that we know where to look if any miss-compilations are discovered. Your careful review of DA looks like a great step forward. If the reported issues break something you are doing with Flang then I will be happy to consider disabling the pass. https://github.com/llvm/llvm-project/pull/140182 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
