> Jakub Jelinek writes:
Jakub> I guess the right thing to do would be to replace the current
Jakub> 3 uses of SYMBOL_REF_LOCAL_P (x) macro in config/rs6000/*.md
Jakub> with
Jakub> SYMBOL_REF_LOCAL_P (x) && (!TARGET_ARCH64 || !SYMBOL_REF_EXTERNAL_P (x))
Jakub> where TARGET_ARCH64 is replaced b
On Mon, Jun 25, 2007 at 12:48:10PM -0400, Mark Mitchell wrote:
> I was suggesting leaving the hook alone, but modifying the test for the
> sibling call optimization in rs6000_function_ok_for_sibcall to:
>
> !DECL_EXTERNAL (decl) && binds_local_p (decl)
>
> In other words, per Jakub's argument,
David Edelsohn wrote:
>> Mark Mitchell writes:
>
> Mark> Good point -- if there's no definition in the current translation unit,
> Mark> then I guess we aren't going to make any bad assumptions about the
> Mark> contents of the function. So, I guess that just means that the Power
> Mark> back
> Mark Mitchell writes:
Mark> Good point -- if there's no definition in the current translation unit,
Mark> then I guess we aren't going to make any bad assumptions about the
Mark> contents of the function. So, I guess that just means that the Power
Mark> back end needs to check for !DECL_EXT
Jakub Jelinek wrote:
> For replacability the current definition is just fine. Weak functions
> must be assumed to be always replaceable and non-weak functions which are
> known to bind within the same executable resp. shared library are not
> replaceable - linker will issue error if two non-weak
On Mon, Jun 25, 2007 at 10:15:55AM -0400, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
>
> >> I think the DECL_EXTERNAL case should go before the visibility checks in
> >> default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally.
> >
> > That isn't the meaning that most callers of
Daniel Jacobowitz wrote:
>> I think the DECL_EXTERNAL case should go before the visibility checks in
>> default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally.
>
> That isn't the meaning that most callers of this function want,
> however. They want same shared object, which is what
On Mon, Jun 25, 2007 at 07:06:01AM -0400, Jakub Jelinek wrote:
> Hi!
>
> extern void bar (void) __attribute__((visibility ("hidden")));
> void foo (void)
> {
> bar ();
> bar ();
> }
> compiled on ppc64-linux with -O2 -m64 -mminimal-toc
> leads to bl bar without nop in the following instruction
On Mon, Jun 25, 2007 at 09:31:14AM -0400, Mark Mitchell wrote:
> David Edelsohn wrote:
>
> > /* If defined in this object and visibility is not default, must be
> > local. */
> > else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
> > local_p = true;
> >
> > Why does binds_local_p
> Mark Mitchell writes:
Mark> I think the DECL_EXTERNAL case should go before the visibility checks in
Mark> default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally.
Jakub,
Do you want to follow up with a patch to change the ordering of
tests in default_binds_local_p_1()
David Edelsohn wrote:
> /* If defined in this object and visibility is not default, must be
> local. */
> else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
> local_p = true;
>
> Why does binds_local_p return true for non-default visibility?
I was just about to ask that.
It's a
On Mon, Jun 25, 2007 at 09:15:40AM -0400, David Edelsohn wrote:
> Emitting a NOP depends on SYMBOL_FLAG_LOCAL.
>
>if (targetm.binds_local_p (decl))
> flags |= SYMBOL_FLAG_LOCAL;
>
> PPC64 uses the default binds_local_p() hook, default_binds_local_p_1():
>
> /* If defined in this
Emitting a NOP depends on SYMBOL_FLAG_LOCAL.
if (targetm.binds_local_p (decl))
flags |= SYMBOL_FLAG_LOCAL;
PPC64 uses the default binds_local_p() hook, default_binds_local_p_1():
/* If defined in this object and visibility is not default, must be
local. */
else if (DECL
> Mark Mitchell writes:
Mark> That would be my recommendation: limit optimizations that require a
Mark> short branch to calls to functions in the same translation unit, not
Mark> just in the same shared object. But, that's just my two cents; the
Mark> Power maintainers might have a different
Jakub Jelinek wrote:
> Hi!
>
> extern void bar (void) __attribute__((visibility ("hidden")));
> void foo (void)
> {
> bar ();
> bar ();
> }
> compiled on ppc64-linux with -O2 -m64 -mminimal-toc
> leads to bl bar without nop in the following instruction
> and to sibling call.
> Shouldn't -mmin
On Mon, Jun 25, 2007 at 07:32:48AM -0400, David Edelsohn wrote:
> > Jakub Jelinek writes:
>
> Jakub> compiled on ppc64-linux with -O2 -m64 -mminimal-toc
> Jakub> leads to bl bar without nop in the following instruction
> Jakub> and to sibling call.
> Jakub> Now, when this together with bar's d
On 6/25/07, David Edelsohn <[EMAIL PROTECTED]> wrote:
Just out of curiosity, are you using a version of GCC with or
without the section anchor support? Is the application still overrunning
the TOC with sectcion anchors?
I have access to programs that overflow the TOC even with section
> Jakub Jelinek writes:
Jakub> compiled on ppc64-linux with -O2 -m64 -mminimal-toc
Jakub> leads to bl bar without nop in the following instruction
Jakub> and to sibling call.
Jakub> Now, when this together with bar's definition is linked
Jakub> into a big binary and foo and bar need to have di
18 matches
Mail list logo
