Live data from Hacker News

Flang: The Fortran frontend of LLVM [video]

fosdem.org

61–70 of 97 posts

Re: Flang: The Fortran frontend of LLVM [video]

#61
post #10

Earlier quoted context omitted.

Ah, ok yes. But in my OP I didn’t really mean technical problems, rather organisational/social. I mean that if all top-class talents in compilers technology focuses on llvm there probably wouldn’t be a lot people to be both willing and able to write alternative backends.

There will always be somebody interested in doing something else. Somebody considers that something can't be represented nicely in LLVM IR and creates their own thing. Somebody can't work with LLVM folks for social reasons and creates their own thing. Reasons there are many and thus at some other point something successful will challenge them. For the C++ world the competition by LLVM/clang was fruitful and triggered…

> Sure, Fortran is a different area, with less commercial interest a d other challenges.

Actually, it's quite the opposite. You're never going to make money selling a C/C++ compiler, but you can make loads of cash selling a Fortran compiler. It's just that the Fortran compiler is likely to come with your supercomputer.

Re: Flang: The Fortran frontend of LLVM [video]

#62
post #56
post #38

Earlier quoted context omitted.

Don’t worry; people said this about GCC (especially once Cygnus got going) and now llvm is challenging GCC. The existence of llvm has caused gcc to improve as well. Gcc (well g++) is still my primary compiler though I do run my code through clang as well as llvm do catch different bugs. I can imagine llvm becoming my primary compiler at some point, but it will still be a few years.

As mostly user of commercial software, it hardly affects me, but it is going to be interesting to watch when all copyleft software gets into a niche and we get back what was basically shareware and PD on the home computing scene.

I'm not sure I understand. Are you predicting that open source is a passing fad, or that is will paint itself into a corner?

Re: Flang: The Fortran frontend of LLVM [video]

#63
post #60

Earlier quoted context omitted.

There will always be somebody interested in doing something else. Somebody considers that something can't be represented nicely in LLVM IR and creates their own thing. Somebody can't work with LLVM folks for social reasons and creates their own thing. Reasons there are many and thus at some other point something successful will challenge them. For the C++ world the competition by LLVM/clang was fruitful and triggered…

I think that is possible. I've been thinking a lot about vectorizing loops recently, especially on AVX512 systems. I've mostly been doing microbenchmarks, and I realize that microbenchmarks might not give a realistic full-program view. LLVM (through Julia and Clang) have a striking performance pattern as sizes vary: https://discourse.julialang.org/t/ann-loopvectorization/3284... They are fast at multiples of 32, but…

I wonder if this means LLVM should behave differently on AMD's Zen 2, which has full speed AVX2 (but no AVX512).

Re: Flang: The Fortran frontend of LLVM [video]

#64
post #2

On one hand this is a great news and as Fortran user pretty happy about it. On the other I’m a bit worried that once LLVM backend will take off for real, so much focus will concentrate on it, that other compilers (PGI, gfortran, Intel Fortran) development will finally stall or even get dropped and we will wake up in future where LLVM behemoth swallowed all the competition. This concern is not only limited to Fortran,…

I am not a compiler expert but I wonder if FORTRAN will lose its speed advantages it still supposedly has if it goes through LLVM.

LLVM's biggest weak spot as a compiler is its lack of good loop nest optimizations. And that hurts Fortran code a lot more than C/C++ code, because your 6-level loop nest code is more likely to be written in Fortran instead of C/C++.

A further point to make is that LLVM IR is strongly biased towards C, and this is especially true when it comes to the memory model. All memory has to be lowered to access via (essentially typeless) pointers, with optional aliasing qualifiers provided via a noalias parameter attribute (which breaks a lot, because restrict isn't all that common in C), and TBAA. And all higher-order information has to be reverse engineered from this starting point.

Re: Flang: The Fortran frontend of LLVM [video]

#65
post #47

Earlier quoted context omitted.

Fortran defaults to no-alias, C and C++ default to may-alias. The annotations exist, but you have to apply them all over the place to get the benefit. It’s doable, but the Fortran model is less error-prone for many users.

Actually, Fortran defines "storage association" rules, so code that doesn't obey them isn't conforming Fortran. I'm not sure about the error-prone, though, from long experience and users arguing with a compiler maintainer. One problem is lack of static checking.

Numeric code rarely (almost never, actually) requires aliasing, so defaulting to no-alias is less error prone for those users. If you’re writing an OS or runtime library, you want aliasing support and static checking, but that’s mostly out-of-scope for Fortran today.

Re: Flang: The Fortran frontend of LLVM [video]

#66
post #2

On one hand this is a great news and as Fortran user pretty happy about it. On the other I’m a bit worried that once LLVM backend will take off for real, so much focus will concentrate on it, that other compilers (PGI, gfortran, Intel Fortran) development will finally stall or even get dropped and we will wake up in future where LLVM behemoth swallowed all the competition. This concern is not only limited to Fortran,…

The great thing is anyone could take the output of the Fortran LLVM front-end, and then compile that however they wanted with their own compiler technology. LLVM doesn't need to mean consolidation of backends. It can just mean you get a front-end for free, if that's all you want.

It's stated that llvm ir is not stable (https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-comp...) and in my relatively limited experience with it there have been enough differences between every little release to make decoupling even official frontend and backend versions not safe or reliable (much less bolting on and maintaining an unofficial backend impl). If bundling/pinning the flang/clang versions with the supported llvm ir version supported by the alternate backend is feasible (which seems sane) then I definitely agree this is an awesome capability (clang-on-sulong) but given how unapologetically volatile llvm ir is I wouldn't exactly call it 'free' :p (but still a lot better than writing a c++ frontend)

Re: Flang: The Fortran frontend of LLVM [video]

#67
post #56

Earlier quoted context omitted.

As mostly user of commercial software, it hardly affects me, but it is going to be interesting to watch when all copyleft software gets into a niche and we get back what was basically shareware and PD on the home computing scene.

I'm not sure I understand. Are you predicting that open source is a passing fad, or that is will paint itself into a corner?

I am predicting that non-copyleft licenses will replace all uses of copyleft licenses, and everyone will get basic functionality in open source with juice bits only avaiable in the commercial versions, just like in the old days before of the rise of GPL.

The evolution of BSD's adoption by commercial entities shows the way.

Re: Flang: The Fortran frontend of LLVM [video]

#68
Aside: this is one thing I found interesting about go. They maintain one compiler and two front ends:

llvm: https://go.googlesource.com/gollvm/

gcc: https://github.com/golang/gofrontend

Go: https://github.com/golang/go/tree/master/src/cmd/compile

And I believe all three are maintained by the go team. It should be noted that the LLVM implementation is used by tinygo: https://tinygo.org/

Re: Flang: The Fortran frontend of LLVM [video]

#69
post #60

Earlier quoted context omitted.

There will always be somebody interested in doing something else. Somebody considers that something can't be represented nicely in LLVM IR and creates their own thing. Somebody can't work with LLVM folks for social reasons and creates their own thing. Reasons there are many and thus at some other point something successful will challenge them. For the C++ world the competition by LLVM/clang was fruitful and triggered…

I think that is possible. I've been thinking a lot about vectorizing loops recently, especially on AVX512 systems. I've mostly been doing microbenchmarks, and I realize that microbenchmarks might not give a realistic full-program view. LLVM (through Julia and Clang) have a striking performance pattern as sizes vary: https://discourse.julialang.org/t/ann-loopvectorization/3284... They are fast at multiples of 32, but…

You should try ISPC if you are this concerned about vectorization. You can try it out on godbolt.org it makes controlling vectorization much easier.

Re: Flang: The Fortran frontend of LLVM [video]

#70
post #2

On one hand this is a great news and as Fortran user pretty happy about it. On the other I’m a bit worried that once LLVM backend will take off for real, so much focus will concentrate on it, that other compilers (PGI, gfortran, Intel Fortran) development will finally stall or even get dropped and we will wake up in future where LLVM behemoth swallowed all the competition. This concern is not only limited to Fortran,…

I'm hoping for Cranelift ( https://github.com/bytecodealliance/cranelift ) to deliver a more JIT-friendly alternative to LLVM (Though it can do AOT compilation too). Another very interesting project, even if it is slightly intimidating in scope, is GraalVM ( https://www.graalvm.org ).

I browsed their github and their linked docs, and it wasn't obvious to me what benefit cranelift has over LLVM. There was one section on implementation differences, but I'm not familiar/smart enough to infer from that what use cases cranelift enables.
Post reply on HN