|
|
Hi,
On Fri, Jul 17, 2009 at 01:04:53PM -0700, Richard Henderson wrote:
> On 07/17/2009 12:30 PM, Martin Jambor wrote:
>> Hi,
>>
>> since the attribute noinline does not prevent ipa-cp cloning from
>> taking place, there has been a need to provide a new attribute to
>> do just that.
>
> What, specifically, is this need?
testsuite/gcc.c-torture/execute/pr17377.c
The testcase assumes noinline implies noclone and thus
__builtin_return_address returns the same addres. But I work on
improving ipa-cp and get the intermediate function cloned and so the
returned address differ and the testcase aborts.
If noinline should not preclude cloning I believe we need a noclone
attribute at least for our testcase.
>
> The way I see it is that your vision in this is too narrow,
> and you're not considering other reasons that a function
> might be cloned.
Yeah, I mesed this up. I was not thinking about the check too much
because I am rewriting much of ipa-cp anyway. But it should go to
tree-inline.c to tree_versionable_function_p(). I will re-post the
patch as soon as I bootstrap and test it.
I'll re post the patch with the check moved there.
> If we add a noclone attribute, and it prohibits all clones,
> then users that think they're working around bugs/misoptimizations
> in ipa-cp may wind up unintentionally prohibiting transactional
> memory clones as well.
Well, that was the idea... except for the bugs in ipa-cp, there should
not be any. OTOH, if any other pass creates clones, it might
introduce problems like the one with pr17377.c testcase too and will
need to be disabled too. Thus noclone should work for all of them.
Martin
|
|