This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Support for architectures without hardware interlocks



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]