Hacker News Reader

Comment by Ididntdothis | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

The Fortran standard just doesn't talk about "aliasing" (in that context), and "defaulting" suggests you can turn off the storage association rules somehow.

I maintain from long research computing experience (at least back to the days of Alliant) that the rules are highly error prone in practice for users, who frequently deny they even exist, and blame the compiler bugs. (I'm surprised if that's not the case more generally.) I'm not saying they shouldn't exist, or that code needs to contravene them.

Yeah, I'm using the C nomenclature ("aliasing" vs "association") because HN commenters are broadly unfamiliar with Fortran.

What I mean by "default" is that if I declare a function with two array arguments in Fortran, with the simplest possible syntax, the compiler assumes that they do not alias (are not associated). By contrast, if I declare a function with two pointer arguments in C, with the simplest possible syntax, the compiler assumes that they may alias (are associated in some unspecified manner).

The C semantics are certainly safer, but they lead to lots of "Fortran is faster than C" blog posts by people who either don't know about or simply don't want to use the annotations.

C has the "restrict" keyword to indicate that no aliasing should occur.

But is mostly unused and mostly irrelevant

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?

Other posters mentioned "restrict". Rust is able to basically use "restrict" on steroids because of how much more info has, so much so that it's brought up bugs in LLVM that are not fixed yet.

https://github.com/rust-lang/rust/issues/54878

I just thought of a stupid question. If gcc and LLVM both support fortran how actually hard would it be really to add real arrays to C? At least as an option? AKA add an option --fortran_arrays.

It has been done multiple times in safe C dialects, the problem is the community, not technical.

A bit of a nitpick maybe, but it's been Fortran and not FORTRAN for quite a while (since Fortran 90 in the 90's).

“since Fortran 90 in the 90's”

That’s when I used it last time :)

still being used in our research group on a daily basis.

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.

Reply on news.ycombinator.com