Re: Support for architectures without hardware interlocks

2015-01-08 Thread Eric Botcazou
> Handling the insertion of the nops at the end of RTL pipe needs to > take also care of branch shortening optimizations, and filling delay > slots. Probably for the given context (only FPU ops) may be a doable > approach. Right, you do it after delay slot filling and before branch shortening. The

RE: Support for architectures without hardware interlocks

2015-01-08 Thread Matthew Fortune
> On 1/8/2015 9:01 AM, Eric Botcazou wrote: > >> I've worked on a gcc target that was porting an architecture without > >> hardware interlock support. Basically, you need to emit nop > >> operations to avoid possible hw conflicts. At the moment, this was > >> done by patching the gcc scheduler to d

Re: Support for architectures without hardware interlocks

2015-01-08 Thread Claudiu Zissulescu
Handling the insertion of the nops at the end of RTL pipe needs to take also care of branch shortening optimizations, and filling delay slots. Probably for the given context (only FPU ops) may be a doable approach. //Claudiu On Thu, Jan 8, 2015 at 4:28 PM, Joel Sherrill wrote: > > On 1/8/2015 9:

RE: Support for architectures without hardware interlocks

2015-01-08 Thread Ajit Kumar Agarwal
-Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Joel Sherrill Sent: Thursday, January 08, 2015 8:59 PM To: Eric Botcazou; Claudiu Zissulescu Cc: gcc@gcc.gnu.org; David Kang Subject: Re: Support for architectures without hardware interlocks On

Re: Support for architectures without hardware interlocks

2015-01-08 Thread Joel Sherrill
On 1/8/2015 9:01 AM, Eric Botcazou wrote: >> I've worked on a gcc target that was porting an architecture without >> hardware interlock support. Basically, you need to emit nop operations >> to avoid possible hw conflicts. At the moment, this was done by >> patching the gcc scheduler to do so, Ano

Re: Support for architectures without hardware interlocks

2015-01-08 Thread Eric Botcazou
> I've worked on a gcc target that was porting an architecture without > hardware interlock support. Basically, you need to emit nop operations > to avoid possible hw conflicts. At the moment, this was done by > patching the gcc scheduler to do so, Another issue to keep is to check > for hardware c

Re: Support for architectures without hardware interlocks

2015-01-08 Thread Claudiu Zissulescu
Hi David, I've worked on a gcc target that was porting an architecture without hardware interlock support. Basically, you need to emit nop operations to avoid possible hw conflicts. At the moment, this was done by patching the gcc scheduler to do so, Another issue to keep is to check for hardware