Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flang: The Fortran frontend of LLVM [video]

fosdem.org

Post reply on HN
Print view View original

41–50 of 97 posts

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

#41

Post by gnufx »

chrisseaton wrote: post #4
tikej wrote: 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.

Is it really that simple (I don't know how decoupled it is.) ? There have been multiple Fortran front ends over the years, albeit not for F2018.

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

#42

Post by gnufx »

Ididntdothis wrote: post #9
tikej wrote: 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.

Flang's code is somewhat slower than gfortran's from comparing the geometric bottom line from the Polyhedron benchmarks on SKX with profile-directed optimization. I won't probably argue argue with arguments about whether that's a reasonable comparison.

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

#43

Post by eru »

ausbah wrote: post #13
tikej wrote: 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,…

What exactly is the benefit of having multiple compilers? I'm not well versed in the area, but it seems like having one compiler is better from the perspectives of standardization, having a single way of handling undefined behaviors, etc?

If you rely on whatever the one true compiler does to undefined behaviour, you are essentially making the compiler the spec.

That's workable, eg for Python (and in practice, Haskell). But is seen as less than ideal.

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

#44

Post by chrisseaton »

gnufx wrote: post #41
chrisseaton wrote: post #4

Earlier quoted context omitted.

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.

Is it really that simple (I don't know how decoupled it is.) ? There have been multiple Fortran front ends over the years, albeit not for F2018.

I think so - I’ve worked on an LLVM backend completely independent of LLVM.

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

#45

Post by Bostonian »

cultus wrote: post #14
tikej wrote: 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 really doubt Intel Fortran will stall. ifort is pretty big business for Intel and the HPC space. It's probably one area where LLVM's advantages don't really matter.

Is ifort "big business" in terms of direct revenues from sales of the compiler or because it makes Intel hardware a faster platform for HPC?

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

#46

Post by bondant »

gnufx wrote: post #40
tikej wrote: 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 haven't seen that talk, but from a previous one, Flang is closely related to the PGI compiler, and F18 is to escape that. I wouldn't miss the grief associated with ifort, which doesn't live up to the mythology. The salient feature of the PGI compiler is probably the offloading, and I assume that's Nvidia-specific, but I don't know how it compares with current, and upcoming, GCC support. The research computing world…

From what I've seen, PGI's offloading (with OpenACC) still delivers better performance than GCC, although GCC is improving. Also PGI usually give better error messages or comments about what it's doing when offloading. But yes offloading with PGI is for Nvidia cards only, and GCC contributors are working on adding support for offloading to AMD GPUs.

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

#47

Post by gnufx »

stephencanon wrote: post #33
cygx wrote: post #24

Earlier quoted context omitted.

C/C++ does not have alias-annotations built-in Restrict?

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.

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

#48

Post by hsivonen »

galangalalgol wrote: post #31
Fronzie wrote: post #12

Earlier quoted context omitted.

As far as I know, the main speed advantage is that Fortran supports arrays, which are known to not alias. C/C++ does not have alias-annotations built-in. Although with template constructs like done in e.g. the Eigen library, alias-optimal code can be generated.

There are bugs in llvm mostly found by rust that are related to this. This will be another source of pressure to fix these bugs, which is good.

My main hope for flang is that it motivates LLVM to fix the Rust-relevant non-aliasing bugs. However, is it actually known that flang/f18 emits IR with the same patterns that exposed the Rust-relevant LLVM bugs?

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

#49

Post by gnufx »

fctorial wrote: post #19

I've never seen a fortram codebase in my life. Is it still alive? What advantages does it offer over C/C++?

Every time Fortran is mentioned, this seems to come up. In one thread I referred to the usage figures for the UK "tier 1" system, for instance.

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

#50

Post by gnufx »

fulafel wrote: post #22
fctorial wrote: post #19

I've never seen a fortram codebase in my life. Is it still alive? What advantages does it offer over C/C++?

It's used in science (physics, chemistry, astronomy etc). Just like C++ is used not because it's a nice language but because of inertia and path dependecy, the same goes for fortran.

But it is a nice enough language, at least in its sphere: "ALGOL 60 is alive and well and living in FORTRAN [sic] 90." -- Tony Hoare
Post reply on HN