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: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>
- To: Joel Sherrill <joel dot sherrill at oarcorp dot com>, 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 15:45:01 +0000
- Subject: RE: Support for architectures without hardware interlocks
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 149.199.60.83) smtp dot mailfrom=ajit dot kumar dot agarwal at xilinx dot com;
- 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>
-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@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 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.
I think this can be done at the machine description md file level with define_delay where the delay slot description can be described.
Thanks & Regards
Ajit
--
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