This is the mail archive of the gcc-bugs@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]

[Bug rtl-optimization/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> 2012-01-11 08:56:27 UTC ---
On Tue, 10 Jan 2012, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176
> 
> Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |ebotcazou at gcc dot
>                    |                            |gnu.org
> 
> --- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-01-10 22:03:43 UTC ---
> > thus there is a store between the load and the zero_extend (and combine
> > only combines forward, not backward):
> > 
> >   /* Verify that I2 and I1 are valid for combining.  */
> >   if (! can_combine_p (i2, i3, i0, i1, NULL_RTX, NULL_RTX, &i2dest, &i2src)
> > 
> > already fails.
> 
> combine is a peephole optimizer so you cannot ask it to combine insns with 8
> other intervening insns between them.  It looks like we have a real problem
> with extensions though and the good approach (backward combining) appears to be
> that of the REE pass, but it's too limited for the time being.

Yeah, it's a bit unfortunate that combines behavior depends on the
insn scheduling ...


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