This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Support for architectures without hardware interlocks
- From: Claudiu Zissulescu <claziss at gmail dot com>
- To: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, David Kang <dkang at isi dot edu>
- Date: Thu, 8 Jan 2015 16:45:19 +0100
- Subject: Re: Support for architectures without hardware interlocks
- Authentication-results: sourceware.org; auth=none
- References: <1804367521 dot 968343 dot 1414782044572 dot JavaMail dot root at zm dot isi dot edu> <1486967563 dot 968382 dot 1414782209571 dot JavaMail dot root at zm dot isi dot edu> <CAL0iMy1ruKdOwsU5nT1cvH10BeVcO7KqPQeH9C_hcSHtcNbbzQ at mail dot gmail dot com> <15967584 dot 8HB6B1dEhE at polaris> <54AEA230 dot 1010307 at oarcorp dot com>
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 <joel.sherrill@oarcorp.com> wrote:
>
> 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, Another issue to keep is to check
>>> for hardware conflicts across basic-block boundaries. And not the
>>> last, is to prohibit/avoid any instruction stream modification after
>>> scheduler (e.g., peephole optimizations etc.).
>> That's an overly complex approach, this usually can be done in a simpler way
>> with a machine-specific pass that runs at the end of the RTL pipeline.
>>
> Isn't this similar to needing to fill a delay slot after a branch
> instruction? My recollection
> is that some SPARC and MIPS have to deal with that.
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherrill@OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
>