> 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
> 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
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:
-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
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
> 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
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