[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower
ppalka at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu Feb 25 05:30:00 GMT 2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ppalka at gcc dot gnu.org
--- Comment #10 from Patrick Palka <ppalka at gcc dot gnu.org> ---
One minor difference between the FEs which can be seen in the gimple dump of
LU.c is that the C++ frontend doesn't transform (a < b ? a : b) to MIN_EXPR (a,
b) whereas the C frontend does perform this transformation. This is because in
fold-const.c the transformation is guarded by:
/* Avoid these transformations if the COND_EXPR may be used
as an lvalue in the C++ front-end. PR c++/19199. */
&& (in_gimple_form
|| VECTOR_TYPE_P (type)
|| (! lang_GNU_CXX ()
&& strcmp (lang_hooks.name, "GNU Objective-C++") != 0)
|| ! maybe_lvalue_p (arg1)
|| ! maybe_lvalue_p (arg2)))
Which deliberately inhibits the transformation for C++. Is this mentioned
lvalued-ness retention still a concern now that the FE performs delayed
folding? By the time the transformation gets performed, the FE will have
lowered all uses of lvalue COND_EXPR to an appropriate non-lvalue COND_EXPR.
Removing this hunk of code passes regtesting, at least.
More information about the Gcc-bugs
mailing list