public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/62080] Suboptimal code generation with eigen library Date: Wed, 27 Aug 2014 09:58:00 -0000 [thread overview] Message-ID: <bug-62080-4-JIsub8MT35@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-62080-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080 --- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Marc Glisse from comment #5) > With the intrinsics patch, I notice that we don't simplify in gimple either: > > _40 = VIEW_CONVERT_EXPR<__m128i>(_39); > MEM[(__m128i * {ref-all})vec_4(D)] = _40; > _60 = MEM[(const double *)vec_4(D)]; > _61 = MEM[(const double *)vec_4(D) + 8B]; > _62 = {_60, _61}; > _63 = VIEW_CONVERT_EXPR<__v4si>(_62); > > (_39 and _63 have the same type) value-numbering has difficulties in seeing through so much stmts (read: not implemented) and it doesn't have a way of expressing "partial" values. That is, it knows that at MEM[(__m128i * {ref-all})vec_4(D)] we stored _39 but when value-numbering the partial reads it can't assign the value _39 to them (as said, "partial" values are not supported). So one way to optimize this is to special-case the composition operations and try looking up a proper memory operation. Another possibility is to value-number compound operations also as piecewise operations, introducing fake value-numbers (that is, "lower" everything to component-wise operations internally). I suppose pattern-matching > _60 = MEM[(const double *)vec_4(D)]; > _61 = MEM[(const double *)vec_4(D) + 8B]; > _62 = {_60, _61}; and generating a single read (with eventually a permute?) would be more profitable and easier to implement.
next prev parent reply other threads:[~2014-08-27 9:58 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-08-10 10:20 [Bug c++/62080] New: " beschindler at gmail dot com 2014-08-10 10:21 ` [Bug c++/62080] " beschindler at gmail dot com 2014-08-10 11:30 ` glisse at gcc dot gnu.org 2014-08-10 12:05 ` beschindler at gmail dot com 2014-08-11 19:16 ` beschindler at gmail dot com 2014-08-11 20:40 ` glisse at gcc dot gnu.org 2014-08-27 9:58 ` rguenth at gcc dot gnu.org [this message] 2020-04-06 9:43 ` [Bug middle-end/62080] " pinskia at gcc dot gnu.org 2020-04-06 10:34 ` glisse at gcc dot gnu.org 2021-07-18 21:18 ` pinskia at gcc dot gnu.org
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-62080-4-JIsub8MT35@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).