[llvm-dev] Pre-RA scheduler does not generate NOPs when getHazardType() returns NoopHazard

[Alex Susu via llvm-dev]

   Hello.
     I am not sure if this is the correct answer to the question I put in the previous 
email, but please take a look at what I wrote in another thread at 
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111293.html .
     Basically, I describe there I was more successful to use PreEmitNoops(), instead of 
the getHazardType() method which, when I return NoopHazard, it does NOT always generate a 
NOP - in my case it works for Store, but not for Load MachineInstructions.

     Does the ScoreboardHazardRecognizer class generate (or not) a NOP instruction, when 
instructed to in getHazardType(), depending on the type of the instruction analyzed?

   Thank you,
     Alex


On 2/12/2017 4:10 AM, Alex Susu wrote:
>   Hello.
>     I am new to the schedulers implemented in the back end of LLVM.
>     I am trying to handle data hazards in my simple processor, with instructions that
> execute in 1 cycle.
>
>     I have tried the standard post-RA scheduler, implemented in
> lib/CodeGen/PostRASchedulerList.cpp, (with a ScoreboardHazardRecognizer), but I have some
> issues with some consecutive instructions that are separated in the final ASM listing and
> they should not.
>
>     I also tried the standard pre-RA scheduler, implemented in
> lib/CodeGen/ScheduleDAGRRList.cpp, (with a ScoreboardHazardRecognizer), but even if I
> report that I have a data hazard in getHazardType() and return NoopHazard, the scheduler
> will not insert a NOP instruction in the respective place where I report the hazard . For
> me it is more convenient, in principle, to use the pre-RA scheduler, but it is not
> generating NOPs.
>     Could you please tell me how can I generate NOPs with a pre-RA scheduler when I am
> already informing it that at the current place we have a NoopHazard.
>
>  Thank you,
>     Alex
>
>   PS: Also, could you please tell me if with the standard pre-RA scheduler with
> ScoreboardHazardRecognizer I could also employ other useful program instructions when
> dealing with hazards, instead of using NOPs.