public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mjr19 at cam dot ac.uk" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/114767] gfortran AVX2 complex multiplication by (0d0,1d0) suboptimal Date: Thu, 18 Apr 2024 17:58:38 +0000 [thread overview] Message-ID: <bug-114767-4-04SNwtE9dk@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114767-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114767 --- Comment #4 from mjr19 at cam dot ac.uk --- An issue which I suspect is related is shown by subroutine zradd(c,n) integer :: i,n complex(kind(1d0)) :: c(*) do i=1,n c(i)=c(i)+1d0 enddo end subroutine If compiled with gfortran-14 and -O3 -mavx2 it all looks very sensible. If one adds -ffast-math, it looks a lot less sensible, and takes over 70% longer to run. I think it has changed from promoting 1d0 to (1d0,0d0) and then adding that (which one might argue that a strict interpretation of the Fortran standard requires, but I am not certain that it does), to collecting all the real parts in a vector, adding 1d0 to them, and avoiding adding 0d0 to the imaginary parts. Unsurprisingly the gain in halving the number of additions is more than offset by the required vperms and vshufs. Ideally -ffast-math would have noticed that adding 0d0 to the imaginary part is not necessary, but then concluded that doing so was faster than any alternative method, and so done so anyway.
next prev parent reply other threads:[~2024-04-18 17:58 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-04-18 12:13 [Bug fortran/114767] New: " mjr19 at cam dot ac.uk 2024-04-18 13:05 ` [Bug tree-optimization/114767] " rguenth at gcc dot gnu.org 2024-04-18 13:58 ` mjr19 at cam dot ac.uk 2024-04-18 17:35 ` roger at nextmovesoftware dot com 2024-04-18 17:58 ` mjr19 at cam dot ac.uk [this message] 2024-04-18 18:01 ` roger at nextmovesoftware dot com 2024-04-19 13:44 ` mjr19 at cam dot ac.uk 2024-05-14 15:30 ` mjr19 at cam dot ac.uk
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-114767-4-04SNwtE9dk@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).