[LLVMdev] splitting a branch within a pseudo

Jim Grosbach grosbach at apple.com
Mon Feb 18 11:34:26 PST 2013


Reed,

Have a look at custom inserters. In particular, how they're used for atomics in the ARM backend.

-Jim

On Feb 17, 2013, at 12:51 PM, Reed Kotler <rkotler at mips.com> wrote:

> After discussions last night, I'm leaning towards going legit with all my pseudo expansions in Mips 16.
> 
> Some I think I can clearly do by just putting in the proper side effects of implicit registers (T8 the condition code register as used by mips 16).
> 
> But I'm still left with some pseudos that have jmp .+4 type instructions in them.
> 
> The original Mips port was to Mips I and Mips I, like Mips 16, has no conditional store instructions.
> 
> There was some super ugly code there to do a test and then branch around the store instruction if the test was not matched. It was quite a large amount of code and I'm not sure I even believe it works. It's long been commented out since we don't even support Mips I anymore.
> 
> I avoided that in Mips 16 by writing some patterns that translate to something like:
> 
> cmp rx, ry  ; implicitly set T8
> btnez foo:  ; branch if T8 not zero
> mov ra, rb
> foo:....
> 
> There is a way to do this in Mips asembler without needing to really create a label. There are builtin forward and backward labels you can use for this and that's what I do in some cases and in other cases I think I just do a .+4 or something.
> 
> SOmething like that. You can see the mips 16 patterns if you want to know the details but they are not important here IMO.
> 
> In principle I should really make machine basic blocks and do all that book keeping but at least the original way is way too complicated and as I said, I'm not sure I believe it even works in all cases. Too many
> complex assumptions about the optimizer and such.
> 
> Any ideas or code pointers for creating the kind of machine basic blocks I would need to do the above without resorting to bundles?
> 
> I like simple.
> 
> Simple usually works always and complex always has at least one more bug. :)
> 
> Tia.
> 
> Reed
> 
> 
> 
> _______________________________________________
> 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