On 1/8/25 10:16 AM, Jan Hubicka wrote:
On Wed, 8 Jan 2025, Jan Hubicka wrote:
On Tue, 10 Dec 2024, Jan Hubicka wrote:
Hi,
int:
struct foo
{
int a;
void bar() const;
~foo()
{
if (a != 42)
__builtin_abort ();
}
};
__attribute__ ((noinline))
void test(const struct foo a)
{
int b = a.a;
a.bar();
if (a.a != b)
__builtin_printf ("optimize me away");
}
struct foo is passed by invisible reference. As discussed in the PR,
since it is declared const, it can not change before function test
returns. This makes it possible to optimize out the conditional.
Doesn't this break the case where 'a' is declared mutable?
Hmm, good point. declaring a mutable definitely lets me to chagne value
in bar. I am adding Jason and Jonatan to CC.
We could probably special case types containing mutable if such code is
valid?
I think there should be a way to figure out already, otherwise a global
const foo x;
would fault if put into .rodata.
cp_apply_type_quals_to_decl drops 'const' if the type has mutable
members. Unfortunately TREE_READONLY on the PARM_DECL isn't helpful in
the case of an invisiref parameter.
But maybe classes with mutable
members are never POD and thus always runtime initialized?
No.
C++ frontend has
/* Nonzero means that this type contains a mutable member. */
#define CLASSTYPE_HAS_MUTABLE(NODE) (LANG_TYPE_CLASS_CHECK (NODE)->has_mutable)
#define TYPE_HAS_MUTABLE_P(NODE) (cp_has_mutable_p (NODE))
but it is not exported to middle-end.
However still this is quite special situation since the object is passed
using invisible reference, so I wonder if in this sicuation a copy is
constructed so the callee can possibly overwrite the muttable fields?
The object bound to the invisible reference is usually a copy, mutable
doesn't make a difference.
Jason
