Why -fPIC stops some optimization?

Why -fPIC stops some optimization?

[Denis Zaitsev]

I have met such a behaviour while compiling GLIBC for x86.  A
construct which suffers looks like:


#define __xyz(x,y,z) ({ \
    ...                 \
    size_t __n= (z);    \
    ...                 \
    switch (__n) {      \
        case ...        \
        ...             \
    }                   \
    ...                 \
})


This macro is intended for use with some constant z
(__builtin_constant_p(z) is true).  And when this macro is used such a
way, GCC should unroll (or what is the word for this?) the switch into
the only branch which is needed.  And GCC does this optimization, but
only not for the -fPIC case.  There GCC emits the whole body for the
switch operator and then does just a jump for the correct branch.
Why?  Or it is some expected misbehaviour for the -fPIC case?

GCC-3.3.2.

Thanks in advance.

Re: Why -fPIC stops some optimization?

[Michel Lespinasse]

On Fri, Jul 09, 2004 at 09:02:30PM +0600, Denis Zaitsev wrote:
> I have met such a behaviour while compiling GLIBC for x86.  A
> construct which suffers looks like:
> 
> 
> #define __xyz(x,y,z) ({ \
>     ...                 \
>     size_t __n= (z);    \
>     ...                 \
>     switch (__n) {      \
>         case ...        \
>         ...             \
>     }                   \
>     ...                 \
> })

I can not comment about your specific case, but in the past I've had a
fairly similar issue with an inline function that had branches and was
supposed to be optimized out to straight-line code at the call site.

Try making __n a const and see if it helps. Yes, this is something
that gcc should really figure it out by itself.

-- 
Michel "Walken" Lespinasse
"In this time of war against Osama bin Laden and the oppressive
Taliban regime, we are thankful that OUR leader isn't the spoiled son
of a powerful politician from a wealthy oil family who is supported by
religious fundamentalists, operates through clandestine organizations,
has no respect for the democratic electoral process, bombs innocents,
and uses war to deny people their civil liberties." --The Boondocks

Re: Why -fPIC stops some optimization?

[Denis Zaitsev]

On Fri, Jul 09, 2004 at 01:45:50PM -0700, Michel Lespinasse wrote:
> On Fri, Jul 09, 2004 at 09:02:30PM +0600, Denis Zaitsev wrote:
> > I have met such a behaviour while compiling GLIBC for x86.  A
> > construct which suffers looks like:
> > 
> > 
> > #define __xyz(x,y,z) ({ \
> >     ...                 \
> >     size_t __n= (z);    \
> >     ...                 \
> >     switch (__n) {      \
> >         case ...        \
> >         ...             \
> >     }                   \
> >     ...                 \
> > })
> 
> I can not comment about your specific case, but in the past I've had a
> fairly similar issue with an inline function that had branches and was
> supposed to be optimized out to straight-line code at the call site.
> 
> Try making __n a const and see if it helps. Yes, this is something
> that gcc should really figure it out by itself.

This is the same way I'm curing the problem for now.  Making the subst
variable const or using (z) directly in a statement-expression really
helps.  But, nevertheless, is this limitation is switch operator
specific?  Or is it a limit for optimization GCC can do, and it's
reached faster when the PIC-code is generated?  Or what's wrong?

Re: Why -fPIC stops some optimization?

[Michel Lespinasse]

On Sat, Jul 10, 2004 at 03:58:01AM +0600, Denis Zaitsev wrote:
> > Try making __n a const and see if it helps. Yes, this is something
> > that gcc should really figure it out by itself.
> 
> This is the same way I'm curing the problem for now.  Making the subst
> variable const or using (z) directly in a statement-expression really
> helps.  But, nevertheless, is this limitation is switch operator
> specific?  Or is it a limit for optimization GCC can do, and it's
> reached faster when the PIC-code is generated?  Or what's wrong?

I can't really help you on this one - I'm just another gcc user.

All I know is, sometimes (often) gcc fails to see that some variable
is only assigned a constant once and never touched anywhere else, and
fails to optimize out that variable as a constant expression. When I
notice this, it's usualy possible to work around the issue by making
that variable a const. I have no idea why gcc does not notice the
obvious by itself though.

Cheers,

-- 
Michel "Walken" Lespinasse
"In this time of war against Osama bin Laden and the oppressive
Taliban regime, we are thankful that OUR leader isn't the spoiled son
of a powerful politician from a wealthy oil family who is supported by
religious fundamentalists, operates through clandestine organizations,
has no respect for the democratic electoral process, bombs innocents,
and uses war to deny people their civil liberties." --The Boondocks