Please make classic Flang to co-exist with LLVM's in-tree Flang

[dmikushin]

In order for this project to ever be useful and accepted by the community, you have to develop a way to integrate it into LLVM toolchain in a non-destructive way.

The idea of planting classic Flang into LLVM toolchain by breaking another Flang project LLVM has is amazingly bad. Why not to break the clang as well? Only by recognizing the importance of others' efforts you get recognized, this is a basic rule. Why do you think you can come and slash another project in favor of yours? The answer is: you don't care, because the downstream vendor releases is the only thing you are interesting in. Please be more thoughtful than narrow corporate goals, you need this for yourself: looking back at your own work, you need to find it meaningful.

As long as this is an opensource project, LLVM and Flang are not your personal toys. Please adjust your decision making to add, not to break things.

[bryanpkc]

Classic Flang predates LLVM Flang, so IMHO it would be wrong to say that Classic Flang "broke" LLVM Flang. LLVM Flang was introduced as a replacement for Classic Flang, and it was not intended for the two frontends to coexist. Some attempts were made to refactor the Classic Flang code to adapt to the new development (e.g. by guarded more downstream code with ENABLE_CLASSIC_FLANG macros), but the work is not trivial and not high on our priority list. Please contribute patches to do this if you care about Classic Flang and would like to get this done.

[ppenzin]

Would it be possible to build classic flang inside of LLVM tree? When the project was started "in tree builds" looked very different from how they do now, maybe with some name disambiguation it would be possible to reduce amount of changes in llvm-project fork and would allow building both compilers side-by-side.

[dmikushin]

@ppenzin , I can share the build scripts that you can experiment with and improve them little by little.

I've learned that statistically normal behavior is that companies only care about the customer requests. There are a few key customers that still depend on this PGI tech and will continue to buy it. Hence are numerous hacks.

[ppenzin]

@dmikushin that'd be appreciated.

I've learned that statistically normal behavior is that companies only care about the customer requests. There are a few key customers that still depend on this PGI tech and will continue to buy it. Hence are numerous hacks.

Yes, I am aware of that, investigating for use with another compilation target, actually 😄

[bryanpkc]

@ppenzin Personally I wish the two frontends would coexist better, and we do welcome contributions from the community to make that happen. Someone made an attempt about a year ago but abandoned the effort later. I have introduced patches that guard Clang driver code with ENABLE_CLASSIC_FLANG macros to make them easier to pick up and refactor, but also do not have time to continue working on it.

If you have any question about the code, please feel free to ask; I'll be happy to help in whatever capacity I can.

[bryanpkc]

About building Classic Flang in-tree, I know that it was supported at one point, but for the past few years nobody has built Classic Flang like that, and I don't think it works any more.

[ppenzin]

@bryanpkc hopefully monorepo provides enough dependency management to eventually make both frontends agree. Thank you for offering to help, I will take a look at the guarded code and reach out with questions.

I am exploring this as a potential frontend for risc-v, by the way.

[bryanpkc]

@ppenzin We have actually done work internally to port Classic Flang to RISC-V. I think we can open-source that work if there is interest.

[ppenzin]

@bryanpkc that would be great! I will be happy to test/help and I think there is wider interest.

[bryanpkc]

@ppenzin Sorry for the lack of update. I've opened #1447 to discuss the RISC-V port. As for the in-tree build, I don't really have time to work on that now, so please feel free to make it work (again) if it is important to you.

[pawosm-arm]

I'm closing it. After many in-house discussions we came to a conclusion that no matter how we look at it, the most reasonable way of having two flangs is to build them separately. I suppose, other contributors share the same or similar view.