This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/17838] spills are not re-used
- From: "tstdenis at elliptictech dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 10 Nov 2011 19:28:33 +0000
- Subject: [Bug rtl-optimization/17838] spills are not re-used
- Auto-submitted: auto-generated
- References: <bug-17838-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17838
--- Comment #9 from Tom St Denis <tstdenis at elliptictech dot com> 2011-11-10 19:28:33 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > Created attachment 25751 [details]
> > Another test case
> >
> > Another example using
> >
> > gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC)
> >
> > The function when compiled with "-m32 -O3" uses way more stack than it should.
> > It's like it's putting the fp_int.dp[] array on the stack...
> >
> > I can confirm this is a problem on 32/64 and ARM as well.
>
> That is a different issue dealing with memcpy works (or does not get
> optimized). File a different bug.
How the hell am I supposed to know that? Maybe the GCC team should clean up
their stack spills once and for all. I'm sure $OBSCURE_PLATFORM_NAME or
$WONDEROUS_NEW_TREE_REPRESENTATION can wait.
I actually have a different routine [fp_mul_comba_small_set.c] from
TomsFastMath that does use memcpy, has the same style of unrolled multipliers,
and does not have this problem.
I can file a new bug if you want, but as a user of GCC I'm not meant to
understand the ins-and-outs of the depths of the compiler. I actually did
search for stack-waste instead of just blindly filing a new report...
/rant