This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix DCE REG_LIBCALL note moving from noop move insns (PR rtl-optimization/33644)


On 10/19/07, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Oct 19, 2007 at 03:04:49PM +0200, Steven Bosscher wrote:
> > > > Compile with -fpic.  There should only be one call to __tls_get_addr
> > > > to get a base address.  Without libcalls there will be two calls.  The
> > > > base address is not exposed in tree-ssa.
> > >
> > > But isn't the function marked const?  (Is that the right flag?)
> >
> > __tls_get_addr is not const, and not pure either.
>
> gcc actually marks them as CONST_OR_PURE_CALL_P (which is a little bit of
> lie, as glibc needs to write some memory as part of resolving __tls_get_addr
> for the first time, but a) nothing actually cares if it is not called at all
> b) nothing cares if it is called just once or several times).

I didn't know that.

So that would mean that you don't even need libcall notes to CSE
_tls_get_addr calls?


> Just tried
> static __thread int a, b;
>
> int foo (void)
> {
>   return a + b;
> }
>
> void bar (int x, int y)
> {
>   a = x;
>   b = y;
> }
>
> with -O2 -m64 -fpic on x86_64 and -O2 -m{32,64} -fpic on ppc64 and while
> 4.1/4.2 have just one __tls_get_addr call in each fn, the trunk has 2 in each.
> CSE does its job, replaces the pseudo set by second REG_RETVAL insn
> by the pseudo set by first REG_RETVAL, but as dce.c doesn't handle libcalls
> properly, nothing ever purges the dead libcall.

What happens if you try this with Eric's patch?

And (more interesting) what happens if you stop gcc from wrapping the
__tls_get_addr sequence in libcall notes?

Gr.
Steven


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]