[llvm-dev] how to prevent LLVM back-end from reordering instructions at instruction scheduling?

[Madhur Amilkanthwar via llvm-dev]

Just a thought. What about putting a dummy barrier between the instructions
during selectionDAG creation?

On Nov 16, 2016 4:00 AM, "Ryan Taylor via llvm-dev" <llvm-dev at lists.llvm.org>
wrote:

> Setting the MI as isTerminator  should have the same impact, yes? I'm not
> sure of the other consequences of this though, if any, have to look into it.
>
> Thanks.
>
> -Ryan
>
> On Tue, Nov 15, 2016 at 5:18 PM, Krzysztof Parzyszek <
> kparzysz at codeaurora.org> wrote:
>
>> You can override TargetInstrInfo::isSchedulingBoundary for that.
>>
>> -Krzysztof
>>
>> On 11/15/2016 4:13 PM, Ryan Taylor wrote:
>>
>>> I have the same issue, would it be easier and more useful to attach a
>>> flag to the instruction to tell the scheduler not to move instructions
>>> across this boundary?
>>>
>>> -Ryan
>>>
>>> On Tue, Nov 15, 2016 at 5:11 PM, Krzysztof Parzyszek via llvm-dev
>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>
>>>     You can create a DAG mutation that adds artificial dependencies
>>>     between A, B and Z.
>>>
>>>     -Krzysztof
>>>
>>>
>>>     On 11/15/2016 3:26 PM, Wei Ding via llvm-dev wrote:
>>>
>>>         Hello,
>>>
>>>         I have a LLVM backend question regarding how to prevent compiler
>>>         from
>>>         reordering instructions. For example, I have the following
>>>         instructions.
>>>         Z_instruction is the one which I want to insert.
>>>
>>>
>>>         // instruction order which I am looking for
>>>         /////////////////////////////////////////
>>>         A_instruction
>>>         B_instruction
>>>
>>>         *Z_instruction*
>>>
>>>         C_instruction
>>>         D_instruction
>>>         E_instruction
>>>         F_instruction
>>>
>>>         *Z_instruction*
>>>
>>>         G_instruction
>>>         F_instruction
>>>
>>>
>>>         ==================================================
>>>
>>>         But I found compiler reordered those instructions like the
>>>         following.
>>>         How could I prevent compiler from moving *A_instruction* and
>>>         *B_instruction* after the first *Z_instruction*? Any
>>>         recommendations and
>>>         suggestion are greatly appreciated here!!!
>>>
>>>         *Z_instruction*
>>>         *
>>>         *
>>>         A_instruction
>>>         B_instruction
>>>
>>>         C_instruction
>>>         D_instruction
>>>         E_instruction
>>>         F_instruction
>>>
>>>         *Z_instruction*
>>>
>>>         G_instruction
>>>         F_instruction
>>>
>>>         BTW, I have define input/output chain for : *C_instruction,
>>>         D_instruction, E_instruction, F_instruction and Z_instruction*
>>>         *
>>>         *
>>>         Thank you so much!
>>>
>>>         --
>>>         Wei Ding
>>>
>>>
>>>         _______________________________________________
>>>         LLVM Developers mailing list
>>>         llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>         http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>         <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>
>>>
>>>     --
>>>     Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>>     hosted by The Linux Foundation
>>>     _______________________________________________
>>>     LLVM Developers mailing list
>>>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>
>>>
>>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by The Linux Foundation
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161116/259186ef/attachment.html>