[LLVMdev] HazardRecognizer and RegisterAllocation

Evan Cheng evan.cheng at apple.com
Mon Jan 19 10:17:06 PST 2009


On Jan 19, 2009, at 9:17 AM, Patrick Boettcher wrote:

> Hi list,
>
> in our LLVM-based-project we are writing a backend for our  
> processor. The
> architecture is a quite straight-forward RISC, but it does not have
> hardware interlocks, i.e. data hazards involving memory access must be
> resolved by the compiler, either by scheduling unrelated  
> instructions or
> by inserting NOOPs into the load delay slots:
>
> ----
>
> For example, code which looks like that:
>
> load 0x1234, reg1
> noop
> noop
> add reg1, 1
> load 0x1236, reg2
>
> can be safely transformed to:
>
> load 0x1234, reg1
> load 0x1236, reg2
> noop
> add reg1, 1
>
> ----
>
> It pleased us quite a lot when we found the HazardRecognizer-class.
> Without much effort we could assist LLVM to transform code like shown
> above (with simple (SDUse, delayCount)-map).
>
> Unfortunately we found now out that the HazardRecognizer is used only
> before register allocation, and the register allocator obviously may
> reschedule instructions, but doesn't take hazard recognition into  
> account.

The register allocator doesn't reschedule code. It can coalesce  
copies, commute instructions, and do re-materialization, etc. It's not  
clear what kind of problems you are running it.

>
>
> Is there a switch/option we overlooked to bind the hazardRecognizer  
> to the
> register-allocator?
>
> And more generally: Is the hazardRecognizer the right and only way to
> solve our NOOP-minimizing problem?

Perhaps you want to do this after register allocation is done. Dan is  
developing the post-allocation scheduler. You can try it out.

Evan

>
>
> thanks for your help in advance,
> Patrick and Christian
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list