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

Re: rs6000 stack_tie mishap again

From: Olivier Hainque <hainque at adacore dot com>
To: Alan Modra <amodra at gmail dot com>
Cc: Olivier Hainque <hainque at adacore dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>
Date: Mon, 11 Apr 2016 12:15:10 +0200
Subject: Re: rs6000 stack_tie mishap again
Authentication-results: sourceware.org; auth=none
References: <DC6B501A-B999-41EC-B3D9-2D04E0A472CD at adacore dot com> <20160324041034 dot GB31470 at bubble dot grove dot modra dot org> <56F96CE2 dot 9020001 at redhat dot com>

> On Mar 28, 2016, at 19:41 , Richard Henderson <rth@redhat.com> 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.

Something like the attached patch, at least for next stage1 until the
more general issue is sorted out ?

Only basic testing at this point. I can do more if considered appropriate.

Thanks for your feedback,

With Kind Regards,

Olivier

	* config/rs6000/rs6000.c (rs6000_emit_stack_tie): Add a
        (clobber mem:BLK (scratch)) to the set of effects, blocking
	all memory accesses.

Attachment: stronger_rs6000_tie.diff
Description: Binary data

Follow-Ups:
- Re: rs6000 stack_tie mishap again
  - From: Andreas Krebbel
- Re: rs6000 stack_tie mishap again
  - From: Segher Boessenkool

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