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 tree-optimization/110035] Missed optimization for dependent assignment statements
Date: Tue, 06 Jun 2023 08:29:58 +0000	[thread overview]
Message-ID: <bug-110035-4-SIxxCsrwCC@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110035-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aagarwa at gcc dot gnu.org,
                   |                            |amonakov at gcc dot gnu.org

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Pontakorn Prasertsuk from comment #12)
> I notice that GCC also does not optimize this case:
> https://godbolt.org/z/7oGqjqqz4

Yes.  To quote:

#include <array>
#include <cstdint>
#include <cstdlib>
#include <iostream>

struct MyClass {
    std::array<uint64_t, 6> arr;
};

MyClass globalA;

// Prevent optimization
void sink(MyClass *m) { std::cout << m->arr[0] << std::endl; }

void __attribute__((noinline)) gg(MyClass &a) {
    MyClass c = a;
    MyClass *b = (MyClass *)malloc(sizeof(MyClass));
    *b = c;
    sink(b);
}

and we do RTL expansion from

  <bb 2> [local count: 1073741824]:
  vect_c_arr__M_elems_0_6.31_25 = MEM <vector(2) long unsigned int> [(long
unsigned int *)a_2(D)];
  vect_c_arr__M_elems_0_6.32_27 = MEM <vector(2) long unsigned int> [(long
unsigned int *)a_2(D) + 16B];
  vect_c_arr__M_elems_0_6.33_29 = MEM <vector(2) long unsigned int> [(long
unsigned int *)a_2(D) + 32B];
  b_4 = malloc (48);
  MEM <vector(2) long unsigned int> [(long unsigned int *)b_4] =
vect_c_arr__M_elems_0_6.31_25;
  MEM <vector(2) long unsigned int> [(long unsigned int *)b_4 + 16B] =
vect_c_arr__M_elems_0_6.32_27;
  MEM <vector(2) long unsigned int> [(long unsigned int *)b_4 + 32B] =
vect_c_arr__M_elems_0_6.33_29;
  sink (b_4); [tail call]

note that the temporary was elided but we specifically avoid TER
(some magic scheduling of stmts in a basic-block) to cross function
calls and there's no optimization phase that would try to optimize
register pressure over calls.  In this case we want to sink the
loads across the call, in other cases we want to avoid doing so.
In the end this would be a job for a late running pass that factors
in things like register pressure and the set of call clobbered register.

I'll note that -fschedule-insns doesn't seem to have any effect here,
but I also remember that scheduling around calls was recently fiddled with,
specifically in r13-5154-g733a1b777f16cd which restricts motion even
with -fsched-pressure (not sure how that honors call clobbered regs).

In the above case the GPR for a_2(D) would be needed after the call
(but there are not call clobbered GPRs) but the three data vectors
in xmm would no longer be live across the call (and all vector registers
are call clobbered on x86).

Of course I'm not sure at all whether RTL scheduling can disambiguate
against a 'malloc' call.

  parent reply	other threads:[~2023-06-06  8:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-30  8:35 [Bug tree-optimization/110035] New: " ptk.prasertsuk at gmail dot com
2023-05-30 11:55 ` [Bug tree-optimization/110035] " rguenth at gcc dot gnu.org
2023-05-30 16:45 ` pinskia at gcc dot gnu.org
2023-05-30 17:22 ` pinskia at gcc dot gnu.org
2023-05-31  1:20 ` ptk.prasertsuk at gmail dot com
2023-05-31  1:46 ` ptk.prasertsuk at gmail dot com
2023-05-31  6:34 ` rguenther at suse dot de
2023-06-03  0:23 ` ptk.prasertsuk at gmail dot com
2023-06-05  7:16 ` rguenth at gcc dot gnu.org
2023-06-05  7:58 ` ptk.prasertsuk at gmail dot com
2023-06-05  8:11 ` rguenther at suse dot de
2023-06-06  5:46 ` ptk.prasertsuk at gmail dot com
2023-06-06  5:49 ` ptk.prasertsuk at gmail dot com
2023-06-06  8:17 ` rguenther at suse dot de
2023-06-06  8:29 ` rguenth at gcc dot gnu.org [this message]
2023-06-06  9:12 ` amonakov at gcc dot gnu.org
2023-06-06 11:54 ` rguenther at suse dot de
2024-05-24  7:50 ` user202729 at protonmail dot com

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-110035-4-SIxxCsrwCC@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: link
Be 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).