[PATCH] D117781: [flang] Update tco tool pipline and add translation to LLVM IR

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added a comment.

In D117781#3314268 <https://reviews.llvm.org/D117781#3314268>, @awarzynski wrote:

> @mehdi_amini, your approval was indeed conditional and we should've followed-up with a discussion on the future of `tco`. In the past, we only briefly discussed replacing it with `flang-new`. That was a while back, **before** `flang-new` could generate MLIR/LLVM IR/a.out. The situation is a bit different now and it does sound like with a bit of extra work we should be able to replace it with other tools. One major outstanding functionality in `flang-new` is the ability to consume MLIR. We've not really looked into it yet, but I can prioritize it.

To be clear: I don't think there is a strong need to change any priority (at least I am not aware of anything).

> Btw, I read @clementval's
>
>> we might change the test to make use of it and maybe retire tco
>
> as:
>
>> it would make sense, but perhaps lets re-visit once upstreaming is complete?

Just note that what you're quoting is not the most recent answer (which was `I guess we can merge the two tools at some point. tco was there before fir-opt so nobody took the time to merge the functionality of one into the other yet.`).

> Quite a few tests in `fir-dev` still use `tco` and retiring it now would require people shifting their focus quite a bit. It will be much easier once `fir-dev` is "read-only".

Yes, which is why I was perfectly fine to add it now to help the upstreaming. But that required an agreement about the future plans, hence the conditional approval. There is no urgency to do anything, if it takes a year to get there it's perfectly fine as well, but there is a difference between "yes this is redundant, 'nobody took the time to merge the functionality' yet, and we'll address this post-upstreaming" and "we don't know what we may or may not want to do".

> Long term, I do support `tco` being retired unless we can identify a unique feature that we cannot replicate with one of the other tools.

I've not been asking anything more than an agreement on this :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117781/new/

https://reviews.llvm.org/D117781