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: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>, Claudiu Zissulescu <claziss at gmail dot com>
- Cc: "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 09:28:48 -0600
- 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>
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