[Bug c++/59739] New: missed optimization: attribute ((pure)) could be honored more often

[Bug c++/59739] New: missed optimization: attribute ((pure)) could be honored more often

[joerg.richter@pdv-fs.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739

            Bug ID: 59739
           Summary: missed optimization: attribute ((pure)) could be
                    honored more often
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joerg.richter@pdv-fs.de

Created attachment 31786
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31786&action=edit
Script for demonstration

Attached is a script (t.sh) that creates two .cc files, compiles and executes
them.

It tests whether attribute ((pure)) is used on different functions with this
signatures:

struct Struct { int val; };
int globalInt();
Struct globalStruct();
struct Class {
  int classInt();
  Struct classStruct();
  virtual int classVirtualInt();
  virtual Struct classVirtualStruct();
};

The output with GCC is 4.8.2 is this:

globalInt: 1
globalStruct: 0
classInt: 1
classStruct: 0
classVirtualInt: 0
classVirtualStruct: 0

Meaning only globalInt and classInt are optimised.

All other functions are also candidates for attribute-pure optimisation.

[Bug c++/59739] missed optimization: attribute ((pure)) could be honored more often

[joerg.richter@pdv-fs.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739

--- Comment #1 from Jörg Richter <joerg.richter@pdv-fs.de> ---
clang seems to optimize all cases.
>From gcc-bugs-return-440462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 15 16:33:39 2014
Return-Path: <gcc-bugs-return-440462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1932 invoked by alias); 15 Jan 2014 16:33:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1509 invoked by uid 48); 15 Jan 2014 16:33:33 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong
Date: Wed, 15 Jan 2014 16:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords: wrong-debug
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-59821-4-pdEM1k1buy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59821-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59821-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg01604.txt.bz2
Content-length: 2287

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY821

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the calls this just happens to work completely by accident, nothing else.
I mean, the default argument expression obviously has location_t from where it
has been defined, i.e. the function/method/ctor definition.  The reason why in
the first case you get the locus of the call is that gimplify_arg sets the
location_t of the arguments to that, but only on the toplevel expression.
Now, in the new case the C++ FE adds an TARGET_EXPR around the default argument
and so during the gimplification it is no longer toplevel expression in the
argument, so gimplify_arg doesn't adjust it.

If you write:
struct Foo
{
  int line;
  Foo (int line = __builtin_LINE () + 1) : line (line) {}
};
int
main ()
{
  if (Foo().line != (new Foo)->line)
    __builtin_abort ();
}

then it will be in both cases the location of the Foo ctor, because the
argument will not be __builtin_LINE() CALL_EXPR as toplevel.

So, IMHO if you want a different behavior, you shouldn't leave this to the
gimplifier, but explicitly change it in the FE.  Say in convert_default_arg or
functions it calls change EXPR_LOCATION of all CALL_EXPRs to the 3 problematic
builtins (I'd argue that only those and nothing else, the expressions really
have locus of where the default argument has been defined and it is desirable
to use that for diagnostic purposes etc.).  convert_default_arg already walks
the expression several times through break_out_target_exprs, so if we e.g.
wanted to
avoid the cost of walking it once again, break_out_target_exprs could have a
flag to tweak location_t of __builtin_{LINE,FILE,FUNCTION}.  Jason, thoughts on
this?  In any case this needs to be documented.  What about other default
locations?  Say if e.g. NSDMI contains __builtin_LINE () call, do we want to
get a value of where the NSDMI is defined, or where the object is constructed?

[Bug c++/59739] missed optimization: attribute ((pure)) could be honored more often

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> ---
CC-ing Honza

[Bug c++/59739] missed optimization: attribute ((pure)) could be honored more often

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-19
                 CC|                            |rguenther at suse dot de
     Ever confirmed|0                           |1

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Confirmed. Actually I think this is more for Richard. The issues here is, I
blieve, the fact that non-gimple-register return values are consiered to be
stores that invalidate the memory context.
It is FRE1 that does the optimization.

[Bug c++/59739] missed optimization: attribute ((pure)) with aggregate returns

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Status|NEW                         |ASSIGNED
                 CC|rguenther at suse dot de           |
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
            Summary|missed optimization:        |missed optimization:
                   |attribute ((pure)) could be |attribute ((pure)) with
                   |honored more often          |aggregate returns

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is rather that value-numbering is SSA based and thus

  D.2954 = globalStruct ();
  _10 = D.2954.val;
  D.2955 = globalStruct ();
  _12 = D.2955.val;

to CSE _12 to _10 we lookup the D.2955.val load and arrive at its def
D.2955 = globalStruct (); from where we can't look further.  FRE
has some tricks to look through aggregate copies but in this case
the aggregate copy source is a function call...

What we'd really need here is to re-write those aggregate temporaries
into SSA form (that also get's us aggregate copyprop for free).  We
can't have partial defs for those, of course, and we'd have to be careful
to not create overlapping life-ranges (because of cost issues - out-of-SSA
will make those "registers" memory again).

Eventually we could do this re-write into SSA form just for SCCVN ...

I don't see how we can easily extend the aggregate copy trick to cover
function calls.

Mine for now.  C testcase:

extern void link_error (void);

struct X { int i; };

struct X foo (void) __attribute__((pure));

int main()
{
  if (foo ().i != foo ().i)
    link_error ();
  return 0;
}

[Bug c++/59739] missed optimization: attribute ((pure)) with aggregate returns

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pskocik at gmail dot com

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 93540 has been marked as a duplicate of this bug. ***

[Bug c++/59739] missed optimization: attribute ((pure)) with aggregate returns

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marco at technoboredom dot net

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 45115 has been marked as a duplicate of this bug. ***

[Bug c++/59739] missed optimization: attribute ((pure)) with aggregate returns

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---

From PR 108635 (via PR 45115), a C++20 testcase where we should be able to
optimize into one call of `operator<=>`:

    #include <compare>

    struct S
    {
        std::weak_ordering operator<=>(const S&) const __attribute__((const));
    };

    int compare3way(S& a, S& b)
    {
        return (a < b) ? -1 : (a > b) ? 1 : 0;
    }