[Bug tree-optimization/53273] New: test-cases suffer from cross-function optimizations with no way to mark limits

[Bug tree-optimization/53273] New: test-cases suffer from cross-function optimizations with no way to mark limits

[hp at gcc dot gnu.org]

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

             Bug #: 53273
           Summary: test-cases suffer from cross-function optimizations
                    with no way to mark limits
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hp@gcc.gnu.org
        Depends on: 53272
              Host: x86_64-unknown-linux-gnu
            Target: crisv32-*


+++ This bug was initially created as a clone of Bug #53272 +++

See PR53272#c1 and the URL.
Putting a function together with main and auxiliary functions causes different
code than when put in separate files (difference present in the .expand dump),
despite adding all currently known attributes to stop that (noinline, noclone,
asm ("")).  If this is deliberate, there must be a future-proof way to stop
such cross-effects, if non-deliberate, it should just be fixed.

Repeat by compiling the test-cases at the URL both separately (at least the
-1.c file) and put in one file, for e.g. crisv32-elf.  Observe differences in
the .expand dump for the rtc_update_irq_enable function when compiled at -O2.

[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits

[hp at gcc dot gnu.org]

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

--- Comment #1 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2012-05-08 23:24:15 UTC ---
Created attachment 27350
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27350
preprocessed file with just the (previously) miscompiled function

This is basically gcc.dg/torture/pr53272-1.c, here for completeness.

[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits

[hp at gcc dot gnu.org]

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

--- Comment #2 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2012-05-08 23:41:41 UTC ---
Created attachment 27351
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27351
Like i2.i (attachment 27350) but with main and auxiliary functions, and always
aborting

This attachment was an edit-in-progress adding functions to make the test-case
runnable, but with an error that isn't in gcc.dg/torture/pr53272-2.c: the
foobar function always aborts, making the test-case always abort.  This leads
to different code being generated for the key function rtc_update_irq_enable. 
The difference seems to be the same as for calling an explicit or computed
noreturn function, which would be an ok optimization if cross-function
optimization was wanted.  Changing the empty line in foobar to "if (foo(x))" as
in gcc.dg/torture/pr53272-2.c yields the expected same generated code as for
i2.i.

So, while it exposes an unwanted optimization, for this case it is benevolent;
the goal was add framework to make the case runnable, not aborting. :)
Though, I bet I can cook up a C++ case that throws (or C that rethrows) before
the aborting call, and the code have the same unwanted difference in presence
of the aborting foobar.

[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits

[hubicka at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-05-08 23:48:06 UTC ---
You seem to be hitting the logic detecting functions executed just once and
making them optimized for size rather than speed.  Usual way to avoid it in the
testsuite is to put a loop into main().

[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #27351|application/octet-stream    |text/plain
          mime type|                            |

--- Comment #4 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2012-05-09 00:01:56 UTC ---
Comment on attachment 27351
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27351
Like i2.i (attachment 27350) but with main and auxiliary functions, and always
aborting

Correcting type of attachment to text/plain.

[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits

[hp at gcc dot gnu.org]

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

--- Comment #5 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2012-05-09 00:04:08 UTC ---
(In reply to comment #3)
> You seem to be hitting the logic detecting functions executed just once and
> making them optimized for size rather than speed.

No, not really "once", but "noreturn".  Maybe both. :/

[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits

[hp at gcc dot gnu.org]

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

--- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2012-05-09 00:13:44 UTC ---
(In reply to comment #3)
> Usual way to avoid it in the
> testsuite is to put a loop into main().

Besides, the background of this PR (at the URL) is that I don't want a recipe
that works for this-optimization and this-code; I want a way to disable
cross-function-optimizations once and for all, preferably with defined
function-granular borders, like disabling in and out of specific functions.

[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The noipa attribute is used for this now.



In this case, adding noipa to foobar, removes the noreturn detection of foobar
and there is no code difference with/without foobar defined in there.


__attribute__ ((noipa))
extern void foobar(void *);

[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits

[hp at gcc dot gnu.org]

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

--- Comment #8 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
There it is!  I *knew* I had a PR entered for this, and was a bit surprised
when the ipa attribute was introduced, that this PR wasn't cross-referenced.

Then again I guess most people don't check in bugzilla for possible entries
when they fix something, and this one maybe hasn't got any good terms to look
for.

(In reply to Andrew Pinski from comment #7)
> The noipa attribute is used for this now.

It sure is and spot on.

[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #8)
> There it is!  I *knew* I had a PR entered for this, and was a bit surprised
> when the ipa attribute was introduced, that this PR wasn't cross-referenced.
> 
> Then again I guess most people don't check in bugzilla for possible entries
> when they fix something, and this one maybe hasn't got any good terms to
> look for.

I think part of it is also finding it independently and fixing it without
looking to see if someone has filed a bug report. I have found a few like this
over the last few years as I try to clean up bugzilla for quality reports.