[PATCH] Inserting directives directly after inline asm blocks

Eric Christopher echristo at gmail.com
Tue Apr 9 16:38:54 PDT 2013


Eh? Which mips target is it doing this for?

-eric

On Tue, Apr 9, 2013 at 4:09 PM, Jack Carter <Jack.Carter at imgtec.com> wrote:
> I would like to insert a Mips specific directive directly after every inline
> asm block. I have done this by exposing AsmPrinter::EmitInlineAsm() and
> making a Mips derivation that calls the parent and then inserts the
> directive. I'm open to other ideas, but this seemed to be the most straight
> forward.
>
> May I check it in?
>
> Background:
>
> The Mips assembler has been around before the compiler could handle things
> like delay slot filling. So, the assembler would move instructions around to
> create and fill the delayslot. The general sequence would look like this:
>
> .set reorder
> add inst
> load inst
> branch and link inst <-- this instruction has a delay slot
> store inst <-- this instruction is suppose to execute after the branch and
> line returns
> load inst
> .set noreorder
>
> This would get transformed by the assembler as:
>
> add inst
> branch and link inst <-- this instruction has a delay slot
> load inst  <-- the load now goes into the delay slot and is executed before
> the branch
> store inst
> load inst
>
> With modern compilers this isn't needed, but we are still saddled with the
> directive .set reorder which is the default state historically. I have
> encountered user code that looks like this:
>
>     // The first word. Notice, no 'D'
>     {asm (
>     ".set noreorder"
>     "lw    %0,%1;"
>     ".set reorder"
>     : "=r" (i)
>     : "m" (*(b+4))
>     );}
>
> The .set reorder  messes with our compiler generated jumps and branches.
>
> GCC gets around this by wrapping each and every branch and jump with .set
> noreorder/reorder pairs. A bit over the top.
>
> Thanks,
>
> Jack
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



More information about the llvm-commits mailing list