This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Attribute noclone
On Fri, 24 Jul 2009, Richard Henderson wrote:
> On 07/24/2009 05:56 AM, Richard Guenther wrote:
> > Users should use noinline if inlining a function would violate constraints
> > they set. I can't see what constraints would not be violated by cloning
> > at the same time.
>
> static void __attribute__((noinline))
> large_stack_usage (int x, int y)
> {
> ...
> }
>
> void
> small_stack_usage (int x)
> {
> if (x)
> large_stack_usage (1, 2);
> }
>
> void
> trans_mem_usage (void)
> {
> __tm_atomic {
> small_stack_usage (1);
> }
> }
>
> We really don't care if large_stack_usage gets cloned with those
> constant parameters. We also wouldn't care if it gets cloned to
> instrument its memory usage for the atomic transaction.
>
> I'm convinced it should be a separate attribute. Though I still
> think noclone is too big of a stick, I don't have a concrete
> suggestion to replace it.
Well, I think that noinline should disable cloning. If it does that
then a separate attribute noclone doesn't make much sense. I don't
understand if you are arguing about having a noclone attribute or
about noinline semantics?
> > Most users will know about inlining but I suspect very few have the
> > idea of the compiler cloning their functions.
>
> Yep, and because of that I don't believe most will have an
> informed opinion as to whether it should be disabled.
Correct.
> I'm totally unconcerned with how __builtin_return_address is
> "affected". It's still doing its job properly. I think it's
> just our documentation that's unnecessarily alarmist.
Ah, I just grepped for noinline in the docs of course. So at least
noclone should be mentioned in these places as well (or they should
not be alarmist and do not mention noinline as well).
Richard.