[LLVMdev] splitting a branch within a pseudo

reed kotler rkotler at mips.com
Mon Feb 18 13:27:21 PST 2013


On 02/18/2013 11:34 AM, Jim Grosbach wrote:
> Reed,
>
> Have a look at custom inserters. In particular, how they're used for atomics in the ARM backend.
>
> -Jim
Nice. I see that we are using them in the Mips backend (probably copied 
from the Arm backend) but I did not work on that code so never paid 
attention to what that was about.

I think I can insert my expansions right there and not have to put them 
into any post isel phases and such.

> 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