[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