[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