[LLVMdev] forcing two instructions to be together

reed kotler rkotler at mips.com
Wed Sep 18 04:46:31 PDT 2013


On 09/17/2013 11:43 PM, Owen Anderson wrote:
> That doesn't actually give you a guarantee that they won't be split up.  Phases other than the scheduler may insert instructions in the middle of block (constant island pass, for example).  Pseudo-instructions are the canonical answer to that problem.

I ended up using a pseudo.

I tried to use bundles but I'm in a hurry and they were causing some 
problem in the code generator that was not obvious to me. It's possible 
that in the exact place I was using them they are not allowed or there 
is some special rule.


> --Owen
>
>
> On Sep 17, 2013, at 11:09 PM, Micah Villmow <micah.villmow at smachines.com> wrote:
>
>> I used the A9 schedule as an example:
>> http://llvm.org/svn/llvm-project/llvm/trunk/lib/Target/ARM/ARMScheduleA9.td
>>
>> The documentation could use more clarity, but this is how I was able to do it to always get two specific instructions to be scheduled together.
>> ________________________________________
>> From: reed kotler [rkotler at mips.com]
>> Sent: Tuesday, September 17, 2013 8:54 PM
>> To: Micah Villmow
>> Cc: Owen Anderson; llvmdev Mailing List
>> Subject: Re: [LLVMdev] forcing two instructions to be together
>>
>> On 09/17/2013 04:51 PM, Micah Villmow wrote:
>>> Reed,
>>>   Couldn't you also use instruction scheduling classes and specify that the second instruction has a bypass from the first instruction? The scheduler should always schedule them together in that case.
>>>
>>> Micah
>>>
>> I'm not sure exactly what you mean.
>>
>> Can you point me to an example of that?
>>
>> TIA.
>>
>> Reed
>>
>>>> -----Original Message-----
>>>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
>>>> Behalf Of reed kotler
>>>> Sent: Tuesday, September 17, 2013 3:59 PM
>>>> To: Owen Anderson
>>>> Cc: llvmdev Mailing List
>>>> Subject: Re: [LLVMdev] forcing two instructions to be together
>>>>
>>>> On 09/17/2013 03:52 PM, Owen Anderson wrote:
>>>>> +the list again
>>>>> On Sep 17, 2013, at 3:48 PM, reed kotler <rkotler at mips.com> wrote:
>>>>>
>>>>>> On 09/17/2013 03:46 PM, Owen Anderson wrote:
>>>>>>> On Sep 17, 2013, at 3:08 PM, reed kotler <rkotler at mips.com> wrote:
>>>>>>>
>>>>>>>> Is there any way, except for using bundles, to force two instructions to be
>>>> sequentially executed?
>>>>>>> What level of codegen are you working at?  There are various mechanisms
>>>> that can be applied, depending on exactly what the constraints are that you
>>>> need to preserve.
>>>>>>> -Owen
>>>>>> I have two machine instructions that I need to be together.
>>>>>>
>>>>>>    BuildMI(MBB, I, DL, TII.get(Mips::LiRxImmAlignX16), V0)
>>>>>>      .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI);
>>>>>>    BuildMI(MBB, I, DL, TII.get(Mips::AddiuRxPcImmX16), V1)
>>>>>>      .addExternalSymbol("_gp_disp", MipsII::MO_ABS_LO);
>>>>>>
>>>>>> It's in Mips16ISelDagToDag.cpp
>>>>>>
>>>>>> these two have to be together because they are both part of a complex pc
>>>> relative calculation.
>>>>>> I have not used bundles yet and was just looking for an easy way to join
>>>> these two.
>>>>> Bundles is one way you can go.  Another is to use a pseudo instruction that is
>>>> broken up immediately before (or during!) MC emission.
>>>>> -Owen
>>>> I just tried this but something is wrong here. Well, I have not used bundles at
>>>> all.
>>>> I just know how they work conceptually. This compiled okay but I got some
>>>> constraint errors.
>>>>
>>>>     MIBundleBuilder(MBB, I)
>>>>       .append(BuildMI(MF, DL, TII.get(Mips::LiRxImmAlignX16), V0)
>>>>           .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI))
>>>>       .append(BuildMI(MF, DL, TII.get(Mips::AddiuRxPcImmX16), V1)
>>>>           .addExternalSymbol("_gp_disp", MipsII::MO_ABS_LO));
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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