On Apr 12, 2012, at 18:07 , Olivier Hainque wrote:
> I'm rebuilding our old compiler with the patch
> and will double check how things go on our original
> failing case.
All is well :) Thanks Alan!
On Apr 12, 2012, at 17:34 , David Edelsohn wrote:
> This version is okay, but I also want to give Richi and Olivier an
> opportunity to comment if they still have any concerns.
Thanks :) I'm rebuilding our old compiler with the patch
and will double check how things go on our original failing c
On Thu, Apr 12, 2012 at 5:34 PM, David Edelsohn wrote:
> On Thu, Apr 12, 2012 at 9:22 AM, Alan Modra wrote:
>
>> I tried that. It doesn't work without something else in the insn to
>> stop rtl-dce deleting it, so you may as well use SETs. But thanks for
>> the prod in the right direction. We d
On Thu, Apr 12, 2012 at 9:22 AM, Alan Modra wrote:
> I tried that. It doesn't work without something else in the insn to
> stop rtl-dce deleting it, so you may as well use SETs. But thanks for
> the prod in the right direction. We do get slightly better results
> when the regs are not hidden a
On Wed, Apr 11, 2012 at 11:00:04AM +0200, Richard Guenther wrote:
> On Wed, Apr 11, 2012 at 6:15 AM, Alan Modra wrote:
> Well - you are expecting generic code to understand your arch-specific
> UNSPEC. It of course cannot.
Right.
> (USE (mem:BLK (reg 1)))
> (CLOBBER (mem:BLK (reg 1)))
>
> re
On Wed, Apr 11, 2012 at 6:15 AM, Alan Modra wrote:
> On Fri, Apr 06, 2012 at 05:25:15PM +0200, Olivier Hainque wrote:
>> Have you discovered where the problem you are still observing
>> is coming from (with another case on 4.4) ? I was planning to look
>> into it and realized that maybe you wer
On Fri, Apr 06, 2012 at 05:25:15PM +0200, Olivier Hainque wrote:
> Have you discovered where the problem you are still observing
> is coming from (with another case on 4.4) ? I was planning to look
> into it and realized that maybe you were already doing so.
In gcc-4.4, alias.c:write_dependence
Hello Alan,
On Apr 6, 2012, at 02:32 , Alan Modra wrote:
[...]
> In the epilogue, the previous frame read must be prevented from moving after
> the stack adjust. If the adjacent write/read uses r1 as a base reg,
> then we don't need a stack tie at all.
Right
> Writes/reads further away won't be
On Thu, Apr 05, 2012 at 07:23:20PM +0200, Olivier Hainque wrote:
> IIUC (please correct me if I'm wrong), every time we need to emit a tie, we
> must ensure that it references all the base regs that were used before to
> restore regs from the frame (to prevent the sp adjustment past the tie from
On Apr 5, 2012, at 16:03 , Alan Modra wrote:
> Well it turns out that gcc-4.4 still gets this testcase from pr30282
> wrong.
Hmph :-(
>> There are lots of places in the emit_epilogue code that assign
>> frame_reg_rtx with different possible values, (hard_fp, sp, r11)
>
> r12 too
Right ...
Hi Olivier,
On Thu, Apr 05, 2012 at 12:36:01PM +0200, Olivier Hainque wrote:
> On Apr 4, 2012, at 03:22 , Alan Modra wrote:
> > I'll see whether my approach fixes pr30282 for gcc-4.4 which has known
> > deficiencies in alias analysis. Olivier, would you be kind enough to
> > backport and test aga
Hello Alan,
On Apr 4, 2012, at 03:22 , Alan Modra wrote:
> I'll see whether my approach fixes pr30282 for gcc-4.4 which has known
> deficiencies in alias analysis. Olivier, would you be kind enough to
> backport and test against other versions of gcc that needed your
> bigger hammer?
Sure. I ca
On Tue, Apr 03, 2012 at 01:05:08PM -0400, David Edelsohn wrote:
> On Tue, Apr 3, 2012 at 10:55 AM, Olivier Hainque wrote:
> >
> > On Apr 3, 2012, at 16:34 , Olivier Hainque wrote:
> >> Thanks a lot for following up on this one. Coincidentally, I was just
> >> about to submit the alternate approach
On Tue, Apr 3, 2012 at 10:55 AM, Olivier Hainque wrote:
>
> On Apr 3, 2012, at 16:34 , Olivier Hainque wrote:
>> Thanks a lot for following up on this one. Coincidentally, I was just
>> about to submit the alternate approach we had discussed about, after
>> David's comment at http://gcc.gnu.org/ml
On Apr 3, 2012, at 16:34 , Olivier Hainque wrote:
> Thanks a lot for following up on this one. Coincidentally, I was just
> about to submit the alternate approach we had discussed about, after
> David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html.
> This is of course a much
Hello Alan,
Thanks a lot for following up on this one. Coincidentally, I was just
about to submit the alternate approach we had discussed about, after
David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html.
We have experienced with it for a while on our gcc-4.5 series of
compi
16 matches
Mail list logo
