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

Reply via email to