On Fri, Apr 15, 2016 at 07:05:25PM +0200, Olivier Hainque wrote:
> > But don't you run the risk that the stack could be deallocated before the
> > restores are done? This came up on the PA port a long time ago. IIRC the
> > situations was something like this:
> >
> > We had a frame pointer and
> On Apr 15, 2016, at 18:42 , Jeff Law wrote:
>> /* (mem:BLK (scratch)) is a special mechanism to conflict with everything.
>> This is used in epilogue deallocation functions. */
> *That's* the one I was looking for :-)
:-)
>> Yes, I pondered this one and thought that a memory barrier
On 04/14/2016 11:10 AM, Olivier Hainque wrote:
On 14 Apr 2016, at 18:50, Jeff Law wrote:
I thought we had code to handle this case specially, but I can't immediately
find it in sched-deps.c.
Unless I misunderstood what you were exactly looking for,
the special code is in alias.c. E.g. writ
> On Apr 15, 2016, at 00:42 , Segher Boessenkool
> wrote:
>
>>
>> Something like the attached patch, at least for next stage1 until the
>> more general issue is sorted out ?
>
> It's a bit heavy; as a workaround, we may want this clobber in the stack
> deallocation in the epilogue, but not in
> On Apr 15, 2016, at 06:37 , Andreas Krebbel
> wrote:
>> /* (mem:BLK (scratch)) is a special mechanism to conflict with everything.
>> This is used in epilogue deallocation functions. */
>> ...
>
> Ok thanks. I've verified that the dependencies are also generated when
> using this expre
On 04/14/2016 07:10 PM, Olivier Hainque wrote:
>
>> On 14 Apr 2016, at 18:50, Jeff Law wrote:
>>
>> I thought we had code to handle this case specially, but I can't immediately
>> find it in sched-deps.c.
>
> Unless I misunderstood what you were exactly looking for,
> the special code is in ali
On Mon, Apr 11, 2016 at 12:15:10PM +0200, Olivier Hainque wrote:
>
> > On Mar 28, 2016, at 19:41 , Richard Henderson wrote:
> >
> > But I expect for stage4, the best solution is to strengthen the stack_tie
> > pattern to block all memory. Early scheduling of the stack frame
> > deallocation (
> On 14 Apr 2016, at 18:50, Jeff Law wrote:
>
> I thought we had code to handle this case specially, but I can't immediately
> find it in sched-deps.c.
Unless I misunderstood what you were exactly looking for,
the special code is in alias.c. E.g. write_dependence_p:
/* (mem:BLK (scratch)) i
On 04/14/2016 09:47 AM, Andreas Krebbel wrote:
On 04/11/2016 12:15 PM, Olivier Hainque wrote:
On Mar 28, 2016, at 19:41 , Richard Henderson wrote:
But I expect for stage4, the best solution is to strengthen the stack_tie
pattern to block all memory. Early scheduling of the stack frame deal
On 04/11/2016 12:15 PM, Olivier Hainque wrote:
>
>> On Mar 28, 2016, at 19:41 , Richard Henderson wrote:
>>
>> But I expect for stage4, the best solution is to strengthen the stack_tie
>> pattern to block all memory. Early scheduling of the stack frame
>> deallocation (a simple logic insn) can
> On Mar 28, 2016, at 19:41 , Richard Henderson wrote:
>
> But I expect for stage4, the best solution is to strengthen the stack_tie
> pattern to block all memory. Early scheduling of the stack frame
> deallocation (a simple logic insn) can't really be that important to
> performance.
Somet
> On Apr 8, 2016, at 17:37 , Segher Boessenkool
> wrote:
>
> On Fri, Apr 08, 2016 at 10:24:50AM +0200, Olivier Hainque wrote:
>>> But I expect for stage4, the best solution is to strengthen the stack_tie
>>> pattern to block all memory. Early scheduling of the stack frame
>>> deallocation (a
On Fri, Apr 08, 2016 at 10:24:50AM +0200, Olivier Hainque wrote:
> > But I expect for stage4, the best solution is to strengthen the stack_tie
> > pattern to block all memory. Early scheduling of the stack frame
> > deallocation (a simple logic insn) can't really be that important to
> > perfor
Hello Richard & Alan,
Thanks for your feedback. Back on it after a few extra
experiments.
> On Mar 28, 2016, at 19:41 , Richard Henderson wrote:
>
>> Let's see what rth thinks. He did say the patch might need to be
>> redone. :)
>> https://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00072.html
>
On Wed, Mar 30, 2016 at 11:02:41AM +0200, Olivier Hainque wrote:
> void g(int, char *);
>
> void f(int x)
> {
>char big[20];
> start:
>g(x, big);
>g(x, big);
>register void *p asm("r11") = &&start;
>asm("" : : "r"(p));
>asm("" : : :"r28");
>
Hello Segher,
> On Mar 28, 2016, at 13:18 , Segher Boessenkool
> wrote:
>
>> You need to have had r11 last used to designate a global
>> symbol as part of the function body (in order to have base_term
>> designate a symbol_ref etc), and then have the scheduler
>> decide that moving across is a
On 03/23/2016 09:10 PM, Alan Modra wrote:
On Wed, Mar 23, 2016 at 05:04:39PM +0100, Olivier Hainque wrote:
The reason why 894 is not accounted in the base ref computation is because it
is part of the epilogue sequence, and init_alias_analysis has:
/* Walk the insns adding values to the n
On Mon, Mar 28, 2016 at 12:45:03PM +0200, Olivier Hainque wrote:
> > The normal -m32 compiler here generates code like
> >
> > lwz 11,0(1)
> >
> > and try as I might I cannot get it to fail. Maybe because the GPR11
> > setup here involves a load?
>
> You need to have had r11 last used to de
> On Mar 28, 2016, at 05:01 , Segher Boessenkool
> wrote:
>
> The normal -m32 compiler here generates code like
>
> lwz 11,0(1)
>
> and try as I might I cannot get it to fail. Maybe because the GPR11
> setup here involves a load?
You need to have had r11 last used to designate a globa
On Wed, Mar 23, 2016 at 05:04:39PM +0100, Olivier Hainque wrote:
> The visible effect is a powerpc-eabispe compiler (no red-zone) producing an
> epilogue sequence like
>
>addi %r11,%r1,184# temp pointer within frame
The normal -m32 compiler here generates code like
lwz 11,0(1)
a
On 03/24/2016 02:17 AM, Olivier Hainque wrote:
[snip]
So, aside from the dependency issue which needs to be fixed somehow, I
think it would make sense to consider using a strong blockage mecanism in
expand_epilogue.
That's what we both said here
https://gcc.gnu.org/ml/gcc-patches/2011-11/msg01
Hello Alan,
> On 24 Mar 2016, at 05:10, Alan Modra wrote:
>
>>if (could_be_prologue_epilogue
>>&& prologue_epilogue_contains (insn))
>> continue;
> https://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00048.html
Ah, interesting, thanks!
>> My rou
> On 24 Mar 2016, at 05:58, Alan Modra wrote:
>
> On Wed, Mar 23, 2016 at 01:38:26PM -0400, David Edelsohn wrote:
>> The description and
>> references to prior SPE prologue and epilogue changes do not confirm a
>> wider problem.
>
> There's a good chance this affects ABI_V4 large stack frames t
On Wed, Mar 23, 2016 at 01:38:26PM -0400, David Edelsohn wrote:
> The description and
> references to prior SPE prologue and epilogue changes do not confirm a
> wider problem.
There's a good chance this affects ABI_V4 large stack frames too.
If restoring regs inline we'll be using r11 as a base, j
On Wed, Mar 23, 2016 at 05:04:39PM +0100, Olivier Hainque wrote:
> The reason why 894 is not accounted in the base ref computation is because it
> is part of the epilogue sequence, and init_alias_analysis has:
>
> /* Walk the insns adding values to the new_reg_base_value array. */
> f
First, SPE has not been maintained and little participation from
Freescale. I would rather deprecate all SPE support. SPE ABI is
broken by design.
I find the approach very heavy-handed. If you want to enable the
target hook for SPE *only*, that's fine with me. The description and
references to
26 matches
Mail list logo
