https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66355
Bug ID: 66355
Summary: defining a constructor inhibits optimization
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kalmquist1 at hotmail dot com
Target Milestone: ---
Created attachment 35659
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35659&action=edit
Archive contains wrap-int-[012].cxx and makefile
Ideally, replacing the type "int" with a wrapper class that contains a single
"int" value as a member should not impose any performance penalty.
Unfortunately, that is not the case if the wrapper class has a non-default
constructor, which it almost certainly will.
The attached archive contains three programs, which can be compiled to assembly
language using the included makefile.
wrap-int-0.cxx contains a very simple integer computation.
wrap-int-1.cxx does the same thing, but the "int" type has been replaced by a
wrapper class. The generated assembly instructions are same, so there is no
performance penalty for using the wrapper class.
wrap-int-2.cxx is the same as wrap-int-1.cxx except that a constructor has been
added to the wrapper class. One would expect a good optimizer to generate the
same code for this program as for the other two programs, but in fact the
generated code is a good deal larger.
I'm guessing that what is happening is that if a type has a non-default
constructor, the C++ front end treats constants of that type as variables
rather than as contstants, so that even simple optimizations like constant
folding are no longer performed by that back end.
