[LLVMdev] Hazard recognizers & basic blocks

[Arnaud Allard de Grandmaison]

Ooops, you are right. Just forgot to CC the mailing list.

Thanks for noticing it,,
--
Arnaud de Grandmaison
________________________________________
From: Damien Vincent [damien.llvm at gmail.com]
Sent: Saturday, February 12, 2011 3:57 AM
To: Arnaud Allard de Grandmaison
Subject: Re: [LLVMdev] Hazard recognizers & basic blocks

Merci !
I was also planning to add a second pass to verify these special cases but wanted to make sure there is not a  simpler and consistent way before proceeding.
And you're right, another way is also to make sure that the final or the first instruction of a basic block are not instructions prone to structural hazards (this should not happen so often...).

Btw, you didn't reply on the mailing list... is it just an omission ? Getting it on the mailing list might be helpful for the llvm community ;)

 Best regards,

  Damien


On Fri, Feb 11, 2011 at 1:30 AM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com<mailto:Arnaud.AllardDeGrandMaison at dibcom.com>> wrote:
Hi Damien,

We also found this issue; our way of solving it was to add a pass after postRAScheduler to handle those inter MBB hazards.
The postRAHazardRecognizer maintains a hazard state inside the basic block, and depending on the successor(s), the hazard are handled inside the current MBB or in the successor. But his gets really tricky when loops are involved. A simple and robust --- but not optimum --- way is to ensure that each MBB ends with no pending hazards.

Best regards,
--
Arnaud de Grandmaison
________________________________
From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu>] On Behalf Of Damien Vincent
Sent: Thursday, February 10, 2011 7:38 PM
To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] Hazard recognizers & basic blocks

To be more specific, let's consider the following (imcomplete) C code (OK, this is not good C style ;) )

{
  ...
  goto label0;
   ...
  goto label1;
  ...

  label0:
  {
  // some C code for basic block starting at label0
   ...
  }
  label1:
  {
  // some C code for basic block starting at label1
  ...
  }
}


In the previous example, the last instruction of basic block0 (starting at label0) is not a jump. There might be a structural hazard between this instruction and the first instruction of basic block1 (starting at label1).

Did you have to deal with this kind of hazards ?

Thanks.

On Thu, Feb 10, 2011 at 10:30 AM, Damien Vincent <damien.llvm at gmail.com<mailto:damien.llvm at gmail.com>> wrote:

  I am working on a target which has some structural hazards.
To detect these hazards, I implemented a sub-class of PostRAHazardRecognizer.

  PostRAHazardRecognizer resets the hazard state on a basic block basis.
  So, how to detect hazards that may occur between the end of a basic block and the beginning of another basic block ?

  Thanks !



________________________________
CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you.


CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you.