tblah wrote: > This looks like it is promoting `-enable-split-sum-expression-tree-lowering` > to a first-class frontend option, just with a different name. What is the > motivation for this?
I originally wanted this to be a driver option, I just wanted to have them as separate commits because I was unsure if the driver option would be controversial. > Do you have a sense of how "useful" this option is for real-world code? It dramatically speeds up one benchmark, and I would expect it to help in other code too although I have not found another example. This is most useful for people diagnosing performance differences between llvm-flang and classic-flang because it reduces one of the major differences in LLVM IR structure. > Can using it lead to incorrect code being generated? Not so far as I know. I think it is legal according to the Fortran standard and there is precedent for this in classic-flang. However it does change the exact floating point results produced by flang for some floating point operations. I would consider enabling this by default once it is more mature. I added it as a hidden option because there is a lot more technical complexity to the consequences of specifying this option relative to most of our user-facing options. It isn't just "go faster": it could change program output (although in what I think is a standards conforming way). I was recalling the RFC to deprecate -Ofast because the author felt that it was too difficult to use. I'm not at all against making it a non-hidden option. https://github.com/llvm/llvm-project/pull/207377 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
