This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why -fPIC stops some optimization?
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?