[llvm-dev] How to constraint instructions reordering from patterns?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] How to constraint instructions reordering from patterns?

Chris Lattner via llvm-dev

Hi,

 

Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization?

I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern.

I’m facing many situations where some patterns are lowered into valid sequences of consecutive SDNodes/Instructions.

Such sequences have no glue, so later during Instruction Scheduling/SelectionDiag linearization the instructions are moved out of valid context.

Is there some Instruction flags or others features that could delimit the reordering could cross some limit?

 

TIA,        Dominique Torette


http://www.spacebel.be/wp-content/uploads/2018/02/image-sign-sbp30y-1.jpg

Dominique Torette
System Architect
Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur
Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20
www.spacebel.be

 


------------------------------------------------------------------------------

E-MAIL DISCLAIMER

The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.

SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.

SPACEBEL denies all liability where E-mail is used for private use.

SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
-------------------------------------------------------------------------------

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] How to constraint instructions reordering from patterns?

Chris Lattner via llvm-dev

Here is a last example to illustrate my concern.

The problem is about the lowering of node t13.

 

Initial selection DAG: BB#0 '_start:entry'

SelectionDAG has 44 nodes:

  t11: i16 = Constant<0>

                  t0: ch = EntryToken

                t3: ch = llvm.clp.set.rspa t0, TargetConstant:i16<392>, Constant:i32<64>

              t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>, Constant:i32<64>

            t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>, Constant:i32<8>

          t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8, ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0, undef:i16

        t16: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t13, ConstantFP:f32<2.000000e+00>, GlobalAddress:i16<float* @x2> 0, undef:i16

      t19: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe418>)> t16, ConstantFP:f32<3.000000e+00>, GlobalAddress:i16<float* @x3> 0, undef:i16

    t22: ch = store<Volatile ST4[@x4](tbaa=<0x3dbe418>)> t19, ConstantFP:f32<4.000000e+00>, GlobalAddress:i16<float* @x4> 0, undef:i16

  t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t22, GlobalAddress:i16<float* @x1> 0, undef:i16

  t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1, GlobalAddress:i16<float* @x2> 0, undef:i16

  t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, GlobalAddress:i16<float* @x3> 0, undef:i16

  t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, GlobalAddress:i16<float* @x4> 0, undef:i16

  t27: i16 = GlobalAddress<float (float, float, float, float)* @fdivfaddfmul_a> 0

  t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4>

  t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, FrameIndex:i16<0>, t29:1

  t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, FrameIndex:i16<1>, t31:1

  t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, FrameIndex:i16<2>, t33:1

  t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, FrameIndex:i16<3>, t35:1

  t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1

  t41: ch,glue = callseq_end t39, TargetConstant:i16<4>, TargetConstant:i16<0>, t39:1

    t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, FrameIndex:i16<0>, t41:1

  t43: ch = CLPISD::RET_FLAG t42:1

 

This node is first ‘combined’ into node t51 (bitcast of ConstantFP f32 to Constant i32).

 

Combining: t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8, ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0, undef:i16

... into: t51: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8, Constant:i32<1065353216>, GlobalAddress:i16<float* @x1> 0, undef:i16

 

An a new Constant:i32 node (t50) is created.

The question is: Where in the graph is created this node?

This node seems to be created before the EntryToken !!! Before the initialization of my Stack Pointer registers (RSPA,RSPB,RSPSU).

Why isn’t it created between t8 and t51?

 

                  t0: ch = EntryToken

                t3: ch = llvm.clp.set.rspa t0, TargetConstant:i16<392>, Constant:i32<64>

              t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>, Constant:i32<64>

            t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>, Constant:i32<8>

          t51: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8, Constant:i32<1065353216>, TargetGlobalAddress:i32<float* @x1> 0, undef:i16

        t49: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t51, Constant:i32<1073741824>, TargetGlobalAddress:i32<float* @x2> 0, undef:i16

      t47: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe418>)> t49, Constant:i32<1077936128>, TargetGlobalAddress:i32<float* @x3> 0, undef:i16

    t45: ch = store<Volatile ST4[@x4](tbaa=<0x3dbe418>)> t47, Constant:i32<1082130432>, TargetGlobalAddress:i32<float* @x4> 0, undef:i16

  t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t45, TargetGlobalAddress:i32<float* @x1> 0, undef:i16

  t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1, TargetGlobalAddress:i32<float* @x2> 0, undef:i16

  t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, TargetGlobalAddress:i32<float* @x3> 0, undef:i16

  t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, TargetGlobalAddress:i32<float* @x4> 0, undef:i16

  t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4>

  t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, TargetFrameIndex:i16<0>, t29:1

  t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, TargetFrameIndex:i16<1>, t31:1

  t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, TargetFrameIndex:i16<2>, t33:1

  t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, TargetFrameIndex:i16<3>, t35:1

  t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1

  t41: ch,glue = callseq_end t39, TargetConstant:i16<4>, TargetConstant:i16<0>, t39:1

    t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, TargetFrameIndex:i16<0>, t41:1

  t43: ch = CLPISD::RET_FLAG t42:1

 

 

ISEL: Starting pattern match on root node: t50: i32 = Constant<1065353216>

 

  Initial Opcode index to 415

  TypeSwitch[i32] from 416 to 432

  Morphed node: t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216>

 

def : Pat<(f32 fpimm:$imm),

                        (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32 f32:$imm))>;

def : Pat<(i32 imm:$imm),

                        (MOVSUTO_A_iSLo (trunc_imm i32:$imm))>;

 

 

===== Instruction selection ends:

Selected selection DAG: BB#0 '_start:entry'

SelectionDAG has 42 nodes:

              t44: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1082130432>

                t46: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1077936128>

                  t48: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1073741824>

                    t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216>

                          t0: ch = EntryToken

                        t3: ch = MOV_SU_iSSs_rspa TargetConstant:i32<64>, t0

                      t5: ch = MOV_SU_iSSs_rspb TargetConstant:i32<64>, t3

                    t8: ch = MOV_SU_iSSs_rspsu TargetConstant:i32<8>, t5

                  t51: ch = MOV_A_or t50, TargetGlobalAddress:i32<float* @x1> 0, t8

                t49: ch = MOV_A_or t48, TargetGlobalAddress:i32<float* @x2> 0, t51

              t47: ch = MOV_A_or t46, TargetGlobalAddress:i32<float* @x3> 0, t49

            t45: ch = MOV_A_or t44, TargetGlobalAddress:i32<float* @x4> 0, t47

          t23: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x1> 0, t45

        t24: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x2> 0, t23:1

      t25: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x3> 0, t24:1

    t26: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x4> 0, t25:1

  t29: ch,glue = CALLSEQ_START TargetConstant:i16<4>, t26:1

 t31: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL TargetGlobalAddress:i32<float* @x1> 0, TargetFrameIndex:i16<0>, t29, t29:1

  t33: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL TargetGlobalAddress:i32<float* @x2> 0, TargetFrameIndex:i16<1>, t31, t31:1

  t35: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL TargetGlobalAddress:i32<float* @x3> 0, TargetFrameIndex:i16<2>, t33, t33:1

  t37: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL TargetGlobalAddress:i32<float* @x4> 0, TargetFrameIndex:i16<3>, t35, t35:1

  t39: ch,glue = CALLSEQ TargetGlobalAddress:i16<float (float, float, float, float)* @fdivfaddfmul_a> 0, t37, t37:1

  t41: ch,glue = CALLSEQ_END TargetConstant:i16<4>, TargetConstant:i16<0>, t39, t39:1

    t42: f32,ch,glue = COPY_TO_CALLER_A TargetFrameIndex:i16<0>, t41, t41:1

  t43: ch = RET_FLAG t42:1

 

From: llvm-dev [mailto:[hidden email]] On Behalf Of Dominique Torette via llvm-dev
Sent: vendredi 4 mai 2018 12:43
To: [hidden email]
Subject: [llvm-dev] How to constraint instructions reordering from patterns?

 

Hi,

 

Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization?

I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern.

I’m facing many situations where some patterns are lowered into valid sequences of consecutive SDNodes/Instructions.

Such sequences have no glue, so later during Instruction Scheduling/SelectionDiag linearization the instructions are moved out of valid context.

Is there some Instruction flags or others features that could delimit the reordering could cross some limit?

 

TIA,        Dominique Torette

http://www.spacebel.be/wp-content/uploads/2018/02/image-sign-sbp30y-1.jpg

Dominique Torette
System Architect
Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur
Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20
www.spacebel.be

 


------------------------------------------------------------------------------

E-MAIL DISCLAIMER

The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.

SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.

SPACEBEL denies all liability where E-mail is used for private use.

SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
-------------------------------------------------------------------------------


------------------------------------------------------------------------------

E-MAIL DISCLAIMER

The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.

SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.

SPACEBEL denies all liability where E-mail is used for private use.

SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
-------------------------------------------------------------------------------

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] How to constraint instructions reordering from patterns?

Chris Lattner via llvm-dev
The DAG dumping will try to print some of the nodes "inline" (i.e. where
they are used) to make the output more readable, so the dump of the DAG
may not strictly reflect the node ordering.

-Krzysztof


On 5/4/2018 8:18 AM, Dominique Torette via llvm-dev wrote:

> Here is a last example to illustrate my concern.
>
> The problem is about the lowering of node t13.
>
> Initial selection DAG: BB#0 '_start:entry'
>
> SelectionDAG has 44 nodes:
>
>    t11: i16 = Constant<0>
>
>                    t0: ch = EntryToken
>
>                  t3: ch = llvm.clp.set.rspa t0, TargetConstant:i16<392>,
> Constant:i32<64>
>
> t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>, Constant:i32<64>
>
>              t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>,
> Constant:i32<8>
>
>            t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
> ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0, undef:i16
>
>          t16: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t13,
> ConstantFP:f32<2.000000e+00>, GlobalAddress:i16<float* @x2> 0, undef:i16
>
>        t19: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe418>)> t16,
> ConstantFP:f32<3.000000e+00>, GlobalAddress:i16<float* @x3> 0, undef:i16
>
>      t22: ch = store<Volatile ST4[@x4](tbaa=<0x3dbe418>)> t19,
> ConstantFP:f32<4.000000e+00>, GlobalAddress:i16<float* @x4> 0, undef:i16
>
> t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t22,
> GlobalAddress:i16<float* @x1> 0, undef:i16
>
>    t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1,
> GlobalAddress:i16<float* @x2> 0, undef:i16
>
>    t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1,
> GlobalAddress:i16<float* @x3> 0, undef:i16
>
>    t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1,
> GlobalAddress:i16<float* @x4> 0, undef:i16
>
>    t27: i16 = GlobalAddress<float (float, float, float, float)*
> @fdivfaddfmul_a> 0
>
>    t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4>
>
>    t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, FrameIndex:i16<0>,
> t29:1
>
>    t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, FrameIndex:i16<1>,
> t31:1
>
>    t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, FrameIndex:i16<2>,
> t33:1
>
>    t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, FrameIndex:i16<3>,
> t35:1
>
>    t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float
> (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1
>
> t41: ch,glue = callseq_end t39, TargetConstant:i16<4>,
> TargetConstant:i16<0>, t39:1
>
> t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, FrameIndex:i16<0>, t41:1
>
>    t43: ch = CLPISD::RET_FLAG t42:1
>
> This node is first ‘combined’ into node t51 (bitcast of ConstantFP f32
> to Constant i32).
>
> Combining: t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
> ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0, undef:i16
>
> ... into: t51: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
> Constant:i32<1065353216>, GlobalAddress:i16<float* @x1> 0, undef:i16
>
> An a new Constant:i32 node (t50) is created.
>
> /The question is: Where in the graph is created this node?/
>
> This node seems to be created before the EntryToken !!! Before the
> initialization of my Stack Pointer registers (RSPA,RSPB,RSPSU).
>
> Why isn’t it created between t8 and t51?
>
> t0: ch = EntryToken
>
>                  t3: ch = llvm.clp.set.rspa t0, TargetConstant:i16<392>,
> Constant:i32<64>
>
>                t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>,
> Constant:i32<64>
>
>              t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>,
> Constant:i32<8>
>
>            t51: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
> Constant:i32<1065353216>, TargetGlobalAddress:i32<float* @x1> 0, undef:i16
>
>          t49: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t51,
> Constant:i32<1073741824>, TargetGlobalAddress:i32<float* @x2> 0, undef:i16
>
>        t47: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe418>)> t49,
> Constant:i32<1077936128>, TargetGlobalAddress:i32<float* @x3> 0, undef:i16
>
>      t45: ch = store<Volatile ST4[@x4](tbaa=<0x3dbe418>)> t47,
> Constant:i32<1082130432>, TargetGlobalAddress:i32<float* @x4> 0, undef:i16
>
> t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t45,
> TargetGlobalAddress:i32<float* @x1> 0, undef:i16
>
>    t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1,
> TargetGlobalAddress:i32<float* @x2> 0, undef:i16
>
>    t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1,
> TargetGlobalAddress:i32<float* @x3> 0, undef:i16
>
>    t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1,
> TargetGlobalAddress:i32<float* @x4> 0, undef:i16
>
>    t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4>
>
>    t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23,
> TargetFrameIndex:i16<0>, t29:1
>
>    t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24,
> TargetFrameIndex:i16<1>, t31:1
>
>    t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25,
> TargetFrameIndex:i16<2>, t33:1
>
>    t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26,
> TargetFrameIndex:i16<3>, t35:1
>
>    t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float
> (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1
>
> t41: ch,glue = callseq_end t39, TargetConstant:i16<4>,
> TargetConstant:i16<0>, t39:1
>
> t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41,
> TargetFrameIndex:i16<0>, t41:1
>
> t43: ch = CLPISD::RET_FLAG t42:1
>
> ISEL: Starting pattern match on root node: t50: i32 = Constant<1065353216>
>
>    Initial Opcode index to 415
>
>    TypeSwitch[i32] from 416 to 432
>
> Morphed node: t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216>
>
> def: Pat<(f32 fpimm:$imm),
>
>                          (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32 f32:$imm))>;
>
> def: Pat<(i32 imm:$imm),
>
>                          (MOVSUTO_A_iSLo (trunc_imm i32:$imm))>;
>
> ===== Instruction selection ends:
>
> Selected selection DAG: BB#0 '_start:entry'
>
> SelectionDAG has 42 nodes:
>
>                t44: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1082130432>
>
>                  t46: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1077936128>
>
>                    t48: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1073741824>
>
> t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216>
>
> t0: ch = EntryToken
>
>                          t3: ch = MOV_SU_iSSs_rspa
> TargetConstant:i32<64>, t0
>
>                        t5: ch = MOV_SU_iSSs_rspb TargetConstant:i32<64>, t3
>
>                      t8: ch = MOV_SU_iSSs_rspsu TargetConstant:i32<8>, t5
>
>                    t51: ch = MOV_A_or t50,
> TargetGlobalAddress:i32<float* @x1> 0, t8
>
>                  t49: ch = MOV_A_or t48, TargetGlobalAddress:i32<float*
> @x2> 0, t51
>
>                t47: ch = MOV_A_or t46, TargetGlobalAddress:i32<float*
> @x3> 0, t49
>
>              t45: ch = MOV_A_or t44, TargetGlobalAddress:i32<float* @x4>
> 0, t47
>
> t23: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x1> 0, t45
>
>          t24: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x2> 0, t23:1
>
>        t25: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x3> 0, t24:1
>
>      t26: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x4> 0, t25:1
>
>    t29: ch,glue = CALLSEQ_START TargetConstant:i16<4>, t26:1
>
>   t31: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
> TargetGlobalAddress:i32<float* @x1> 0, TargetFrameIndex:i16<0>, t29, t29:1
>
>    t33: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
> TargetGlobalAddress:i32<float* @x2> 0, TargetFrameIndex:i16<1>, t31, t31:1
>
>    t35: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
> TargetGlobalAddress:i32<float* @x3> 0, TargetFrameIndex:i16<2>, t33, t33:1
>
>    t37: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
> TargetGlobalAddress:i32<float* @x4> 0, TargetFrameIndex:i16<3>, t35, t35:1
>
>    t39: ch,glue = CALLSEQ TargetGlobalAddress:i16<float (float, float,
> float, float)* @fdivfaddfmul_a> 0, t37, t37:1
>
>    t41: ch,glue = CALLSEQ_END TargetConstant:i16<4>,
> TargetConstant:i16<0>, t39, t39:1
>
>      t42: f32,ch,glue = COPY_TO_CALLER_A TargetFrameIndex:i16<0>, t41, t41:1
>
> t43: ch = RET_FLAG t42:1
>
> *From:*llvm-dev [mailto:[hidden email]] *On Behalf Of
> *Dominique Torette via llvm-dev
> *Sent:* vendredi 4 mai 2018 12:43
> *To:* [hidden email]
> *Subject:* [llvm-dev] How to constraint instructions reordering from
> patterns?
>
> Hi,
>
> Is there a kind of scope mechanism in the instruction lowering pattern
> language in order to control where instructions are inserted or how they
> are later reordered during the SelectionDiag linearization?
>
> I know the glue chain that stick instructions together. But such
> mechanism in not provided in instruction lowering pattern.
>
> I’m facing many situations where some patterns are lowered into valid
> sequences of consecutive SDNodes/Instructions.
>
> Such sequences have no glue, so later during Instruction
> Scheduling/SelectionDiag linearization the instructions are moved out of
> valid context.
>
> Is there some Instruction flags or others features that could delimit
> the reordering could cross some limit?
>
> TIA,        Dominique Torette
>
> http://www.spacebel.be/wp-content/uploads/2018/02/image-sign-sbp30y-1.jpg
>
> *Dominique Torette*
> System Architect
> Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur
> Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20
> www.spacebel.be <http://www.spacebel.be/>
>
>
> ------------------------------------------------------------------------------
>
> E-MAIL DISCLAIMER
>
> The present message may contain confidential and/or legally privileged
> information. If you are not the intended addressee and in case of a
> transmission error, please notify the sender immediately and destroy
> this E-mail. Disclosure, reproduction or distribution of this document
> and its possible attachments is strictly forbidden.
>
> SPACEBEL denies all liability for incomplete, improper, inaccurate,
> intercepted, (partly) destroyed, lost and/or belated transmission of the
> current information given that unencrypted electronic transmission
> cannot currently be guaranteed to be secure or error free.
> Upon request or in conformity with formal, contractual agreements, an
> originally signed hard copy will be sent to you to confirm the
> information contained in this E-mail.
>
> SPACEBEL denies all liability where E-mail is used for private use.
>
> SPACEBEL cannot be held responsible for possible viruses that might
> corrupt this message and/or your computer system.
> -------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
>
> E-MAIL DISCLAIMER
>
> The present message may contain confidential and/or legally privileged
> information. If you are not the intended addressee and in case of a
> transmission error, please notify the sender immediately and destroy
> this E-mail. Disclosure, reproduction or distribution of this document
> and its possible attachments is strictly forbidden.
>
> SPACEBEL denies all liability for incomplete, improper, inaccurate,
> intercepted, (partly) destroyed, lost and/or belated transmission of the
> current information given that unencrypted electronic transmission
> cannot currently be guaranteed to be secure or error free.
> Upon request or in conformity with formal, contractual agreements, an
> originally signed hard copy will be sent to you to confirm the
> information contained in this E-mail.
>
> SPACEBEL denies all liability where E-mail is used for private use.
>
> SPACEBEL cannot be held responsible for possible viruses that might
> corrupt this message and/or your computer system.
> -------------------------------------------------------------------------------
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] How to constraint instructions reordering from patterns?

Chris Lattner via llvm-dev
Krzysztof,
Thanks for your interest to my questions.
In order to clarify the context, here is the C source file of my test case.
The 3 builtins initialize some stack pointers. They have to be executed before any other instruction.
 
 
extern float fdivfaddfmul_a(float a, float b, float c, float d);

volatile static float   x1,x2,x3,x4;

void _start(void)
{
        float   res;

        __builtin_clp_set_rspa(64);
        __builtin_clp_set_rspb(64);
        __builtin_clp_set_rspsu(8);

        x1 = 1.0f;
        x2 = 2.0f;
        x3 = 3.0f;
        x4 = 4.0f;

        res = fdivfaddfmul_a(x1,x2,x3,x4);
}

-----Original Message-----
From: llvm-dev [mailto:[hidden email]] On Behalf Of Krzysztof Parzyszek via llvm-dev
Sent: vendredi 4 mai 2018 15:42
To: [hidden email]
Subject: Re: [llvm-dev] How to constraint instructions reordering from patterns?

The DAG dumping will try to print some of the nodes "inline" (i.e. where they are used) to make the output more readable, so the dump of the DAG may not strictly reflect the node ordering.

-Krzysztof


On 5/4/2018 8:18 AM, Dominique Torette via llvm-dev wrote:

> Here is a last example to illustrate my concern.
>
> The problem is about the lowering of node t13.
>
> Initial selection DAG: BB#0 '_start:entry'
>
> SelectionDAG has 44 nodes:
>
>    t11: i16 = Constant<0>
>
>                    t0: ch = EntryToken
>
>                  t3: ch = llvm.clp.set.rspa t0,
> TargetConstant:i16<392>, Constant:i32<64>
>
> t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>,
> Constant:i32<64>
>
>              t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>,
> Constant:i32<8>
>
>            t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
> ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0,
> undef:i16
>
>          t16: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t13,
> ConstantFP:f32<2.000000e+00>, GlobalAddress:i16<float* @x2> 0,
> undef:i16
>
>        t19: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe418>)> t16,
> ConstantFP:f32<3.000000e+00>, GlobalAddress:i16<float* @x3> 0,
> undef:i16
>
>      t22: ch = store<Volatile ST4[@x4](tbaa=<0x3dbe418>)> t19,
> ConstantFP:f32<4.000000e+00>, GlobalAddress:i16<float* @x4> 0,
> undef:i16
>
> t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t22,
> GlobalAddress:i16<float* @x1> 0, undef:i16
>
>    t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1,
> GlobalAddress:i16<float* @x2> 0, undef:i16
>
>    t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1,
> GlobalAddress:i16<float* @x3> 0, undef:i16
>
>    t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1,
> GlobalAddress:i16<float* @x4> 0, undef:i16
>
>    t27: i16 = GlobalAddress<float (float, float, float, float)*
> @fdivfaddfmul_a> 0
>
>    t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4>
>
>    t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23,
> FrameIndex:i16<0>,
> t29:1
>
>    t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24,
> FrameIndex:i16<1>,
> t31:1
>
>    t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25,
> FrameIndex:i16<2>,
> t33:1
>
>    t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26,
> FrameIndex:i16<3>,
> t35:1
>
>    t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float
> (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1
>
> t41: ch,glue = callseq_end t39, TargetConstant:i16<4>,
> TargetConstant:i16<0>, t39:1
>
> t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, FrameIndex:i16<0>,
> t41:1
>
>    t43: ch = CLPISD::RET_FLAG t42:1
>
> This node is first ‘combined’ into node t51 (bitcast of ConstantFP f32
> to Constant i32).
>
> Combining: t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
> ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0,
> undef:i16
>
> ... into: t51: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
> Constant:i32<1065353216>, GlobalAddress:i16<float* @x1> 0, undef:i16
>
> An a new Constant:i32 node (t50) is created.
>
> /The question is: Where in the graph is created this node?/
>
> This node seems to be created before the EntryToken !!! Before the
> initialization of my Stack Pointer registers (RSPA,RSPB,RSPSU).
>
> Why isn’t it created between t8 and t51?
>
> t0: ch = EntryToken
>
>                  t3: ch = llvm.clp.set.rspa t0,
> TargetConstant:i16<392>, Constant:i32<64>
>
>                t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>,
> Constant:i32<64>
>
>              t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>,
> Constant:i32<8>
>
>            t51: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
> Constant:i32<1065353216>, TargetGlobalAddress:i32<float* @x1> 0,
> undef:i16
>
>          t49: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t51,
> Constant:i32<1073741824>, TargetGlobalAddress:i32<float* @x2> 0,
> undef:i16
>
>        t47: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe418>)> t49,
> Constant:i32<1077936128>, TargetGlobalAddress:i32<float* @x3> 0,
> undef:i16
>
>      t45: ch = store<Volatile ST4[@x4](tbaa=<0x3dbe418>)> t47,
> Constant:i32<1082130432>, TargetGlobalAddress:i32<float* @x4> 0,
> undef:i16
>
> t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t45,
> TargetGlobalAddress:i32<float* @x1> 0, undef:i16
>
>    t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1,
> TargetGlobalAddress:i32<float* @x2> 0, undef:i16
>
>    t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1,
> TargetGlobalAddress:i32<float* @x3> 0, undef:i16
>
>    t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1,
> TargetGlobalAddress:i32<float* @x4> 0, undef:i16
>
>    t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4>
>
>    t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23,
> TargetFrameIndex:i16<0>, t29:1
>
>    t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24,
> TargetFrameIndex:i16<1>, t31:1
>
>    t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25,
> TargetFrameIndex:i16<2>, t33:1
>
>    t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26,
> TargetFrameIndex:i16<3>, t35:1
>
>    t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float
> (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1
>
> t41: ch,glue = callseq_end t39, TargetConstant:i16<4>,
> TargetConstant:i16<0>, t39:1
>
> t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41,
> TargetFrameIndex:i16<0>, t41:1
>
> t43: ch = CLPISD::RET_FLAG t42:1
>
> ISEL: Starting pattern match on root node: t50: i32 =
> Constant<1065353216>
>
>    Initial Opcode index to 415
>
>    TypeSwitch[i32] from 416 to 432
>
> Morphed node: t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216>
>
> def: Pat<(f32 fpimm:$imm),
>
>                          (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32
> f32:$imm))>;
>
> def: Pat<(i32 imm:$imm),
>
>                          (MOVSUTO_A_iSLo (trunc_imm i32:$imm))>;
>
> ===== Instruction selection ends:
>
> Selected selection DAG: BB#0 '_start:entry'
>
> SelectionDAG has 42 nodes:
>
>                t44: i32 = MOVSUTO_A_iSLo
> TargetConstant:i32<1082130432>
>
>                  t46: i32 = MOVSUTO_A_iSLo
> TargetConstant:i32<1077936128>
>
>                    t48: i32 = MOVSUTO_A_iSLo
> TargetConstant:i32<1073741824>
>
> t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216>
>
> t0: ch = EntryToken
>
>                          t3: ch = MOV_SU_iSSs_rspa
> TargetConstant:i32<64>, t0
>
>                        t5: ch = MOV_SU_iSSs_rspb
> TargetConstant:i32<64>, t3
>
>                      t8: ch = MOV_SU_iSSs_rspsu TargetConstant:i32<8>,
> t5
>
>                    t51: ch = MOV_A_or t50,
> TargetGlobalAddress:i32<float* @x1> 0, t8
>
>                  t49: ch = MOV_A_or t48,
> TargetGlobalAddress:i32<float* @x2> 0, t51
>
>                t47: ch = MOV_A_or t46, TargetGlobalAddress:i32<float*
> @x3> 0, t49
>
>              t45: ch = MOV_A_or t44, TargetGlobalAddress:i32<float*
> @x4> 0, t47
>
> t23: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x1> 0, t45
>
>          t24: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x2> 0,
> t23:1
>
>        t25: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x3> 0,
> t24:1
>
>      t26: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x4> 0,
> t25:1
>
>    t29: ch,glue = CALLSEQ_START TargetConstant:i16<4>, t26:1
>
>   t31: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
> TargetGlobalAddress:i32<float* @x1> 0, TargetFrameIndex:i16<0>, t29,
> t29:1
>
>    t33: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
> TargetGlobalAddress:i32<float* @x2> 0, TargetFrameIndex:i16<1>, t31,
> t31:1
>
>    t35: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
> TargetGlobalAddress:i32<float* @x3> 0, TargetFrameIndex:i16<2>, t33,
> t33:1
>
>    t37: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
> TargetGlobalAddress:i32<float* @x4> 0, TargetFrameIndex:i16<3>, t35,
> t35:1
>
>    t39: ch,glue = CALLSEQ TargetGlobalAddress:i16<float (float, float,
> float, float)* @fdivfaddfmul_a> 0, t37, t37:1
>
>    t41: ch,glue = CALLSEQ_END TargetConstant:i16<4>,
> TargetConstant:i16<0>, t39, t39:1
>
>      t42: f32,ch,glue = COPY_TO_CALLER_A TargetFrameIndex:i16<0>, t41,
> t41:1
>
> t43: ch = RET_FLAG t42:1
>
> *From:*llvm-dev [mailto:[hidden email]] *On Behalf Of
> *Dominique Torette via llvm-dev
> *Sent:* vendredi 4 mai 2018 12:43
> *To:* [hidden email]
> *Subject:* [llvm-dev] How to constraint instructions reordering from
> patterns?
>
> Hi,
>
> Is there a kind of scope mechanism in the instruction lowering pattern
> language in order to control where instructions are inserted or how
> they are later reordered during the SelectionDiag linearization?
>
> I know the glue chain that stick instructions together. But such
> mechanism in not provided in instruction lowering pattern.
>
> I’m facing many situations where some patterns are lowered into valid
> sequences of consecutive SDNodes/Instructions.
>
> Such sequences have no glue, so later during Instruction
> Scheduling/SelectionDiag linearization the instructions are moved out
> of valid context.
>
> Is there some Instruction flags or others features that could delimit
> the reordering could cross some limit?
>
> TIA,        Dominique Torette
>
> http://www.spacebel.be/wp-content/uploads/2018/02/image-sign-sbp30y-1.
> jpg
>
> *Dominique Torette*
> System Architect
> Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur
> Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20 www.spacebel.be
> <http://www.spacebel.be/>
>
>
> ----------------------------------------------------------------------
> --------
>
> E-MAIL DISCLAIMER
>
> The present message may contain confidential and/or legally privileged
> information. If you are not the intended addressee and in case of a
> transmission error, please notify the sender immediately and destroy
> this E-mail. Disclosure, reproduction or distribution of this document
> and its possible attachments is strictly forbidden.
>
> SPACEBEL denies all liability for incomplete, improper, inaccurate,
> intercepted, (partly) destroyed, lost and/or belated transmission of
> the current information given that unencrypted electronic transmission
> cannot currently be guaranteed to be secure or error free.
> Upon request or in conformity with formal, contractual agreements, an
> originally signed hard copy will be sent to you to confirm the
> information contained in this E-mail.
>
> SPACEBEL denies all liability where E-mail is used for private use.
>
> SPACEBEL cannot be held responsible for possible viruses that might
> corrupt this message and/or your computer system.
> ----------------------------------------------------------------------
> ---------
>
>
> ----------------------------------------------------------------------
> --------
>
> E-MAIL DISCLAIMER
>
> The present message may contain confidential and/or legally privileged
> information. If you are not the intended addressee and in case of a
> transmission error, please notify the sender immediately and destroy
> this E-mail. Disclosure, reproduction or distribution of this document
> and its possible attachments is strictly forbidden.
>
> SPACEBEL denies all liability for incomplete, improper, inaccurate,
> intercepted, (partly) destroyed, lost and/or belated transmission of
> the current information given that unencrypted electronic transmission
> cannot currently be guaranteed to be secure or error free.
> Upon request or in conformity with formal, contractual agreements, an
> originally signed hard copy will be sent to you to confirm the
> information contained in this E-mail.
>
> SPACEBEL denies all liability where E-mail is used for private use.
>
> SPACEBEL cannot be held responsible for possible viruses that might
> corrupt this message and/or your computer system.
> ----------------------------------------------------------------------
> ---------
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://clicktime.symantec.com/a/1/tbxVxIV7NHJU6POiwH5_tDw_2PbTppHxSRt
> jhMPVRc8=?d=ALAuPK9uzEDDOpSYAAGYWzyuqN7RRKDngCDIjmR6RSRDIrTp2qQBQqBjQ3
> ILzf8fK97r5NNx_DkO4WlhMvPy87cqHb6S6izr4tRxwztngStrqoULJ7BvfXEG1f3dBSX3
> kB4JxllT8TVif5Dp5M-mfh1Xqfd2XxLdTkkCddhqxvYuCrH4VWXYwBJvB_4HM1ZeLVprLg
> hRH5WMIntD1QbyKdXGArxFb0HvBgGscGE36KGxD0vNFsg3OhCyq7Iyb5JSQAlTgxSA4Xe_
> EDpBump-g5fSCyrRVAu0q2qtWgIW1uZRKRmOanzj3UE4nr4iqAL9JAaJHLNwYJW6W9jdmo
> IkmFjH1oqKFguA_uviZrKPLNulEuCLLRfb7yRZWTnaza3I_n7kOSaKaE5Yc9hJsv84M-Kn
> _kGBySXXHpMz47Ftafa8ZlH1OCtzWSD2whMUAQ%3D%3D&u=http%3A%2F%2Flists.llvm
> .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev
>

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________
LLVM Developers mailing list
[hidden email]
https://clicktime.symantec.com/a/1/tbxVxIV7NHJU6POiwH5_tDw_2PbTppHxSRtjhMPVRc8=?d=ALAuPK9uzEDDOpSYAAGYWzyuqN7RRKDngCDIjmR6RSRDIrTp2qQBQqBjQ3ILzf8fK97r5NNx_DkO4WlhMvPy87cqHb6S6izr4tRxwztngStrqoULJ7BvfXEG1f3dBSX3kB4JxllT8TVif5Dp5M-mfh1Xqfd2XxLdTkkCddhqxvYuCrH4VWXYwBJvB_4HM1ZeLVprLghRH5WMIntD1QbyKdXGArxFb0HvBgGscGE36KGxD0vNFsg3OhCyq7Iyb5JSQAlTgxSA4Xe_EDpBump-g5fSCyrRVAu0q2qtWgIW1uZRKRmOanzj3UE4nr4iqAL9JAaJHLNwYJW6W9jdmoIkmFjH1oqKFguA_uviZrKPLNulEuCLLRfb7yRZWTnaza3I_n7kOSaKaE5Yc9hJsv84M-Kn_kGBySXXHpMz47Ftafa8ZlH1OCtzWSD2whMUAQ%3D%3D&u=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev

 ------------------------------------------------------------------------------

E-MAIL DISCLAIMER

The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.

SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.

SPACEBEL denies all liability where E-mail is used for private use.

SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
 -------------------------------------------------------------------------------
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] How to constraint instructions reordering from patterns?

Chris Lattner via llvm-dev
Resending the reply to include the mailing list:

Hi Dominique,

The topological sorting of the DAG only takes into consideration edges
of the graph, so unless the requirements of the intrinsics are somehow
represented in the graph, the instruction selection won't be able to
ensure that they are always the first.
One way to accomplish what you are trying to do would be to override
EmitFunctionEntryCode, and in that function scan CurDAG for these
intrinsics and for each one of them emit the corresponding instructions
directly. After that, these intrinsics would still be present in the
DAG, so the selection code could simply ignore them.
This would only work if the intrinsics are in the entry block in the
source code, since instruction selection only works on a single block at
a time.

-Krzysztof


On 5/4/2018 9:11 AM, Dominique Torette wrote:

> Krzysztof,
> Thanks for your interest to my questions.
> In order to clarify the context, here is the C source file of my test case.
> The 3 builtins initialize some stack pointers. They have to be executed before any other instruction.
>  
>  
> extern float fdivfaddfmul_a(float a, float b, float c, float d);
>
> volatile static float   x1,x2,x3,x4;
>
> void _start(void)
> {
>          float   res;
>
>          __builtin_clp_set_rspa(64);
>          __builtin_clp_set_rspb(64);
>          __builtin_clp_set_rspsu(8);
>
>          x1 = 1.0f;
>          x2 = 2.0f;
>          x3 = 3.0f;
>          x4 = 4.0f;
>
>          res = fdivfaddfmul_a(x1,x2,x3,x4);
> }
>
> -----Original Message-----
> From: llvm-dev [mailto:[hidden email]] On Behalf Of Krzysztof Parzyszek via llvm-dev
> Sent: vendredi 4 mai 2018 15:42
> To: [hidden email]
> Subject: Re: [llvm-dev] How to constraint instructions reordering from patterns?
>
> The DAG dumping will try to print some of the nodes "inline" (i.e. where they are used) to make the output more readable, so the dump of the DAG may not strictly reflect the node ordering.
>
> -Krzysztof
>
>
> On 5/4/2018 8:18 AM, Dominique Torette via llvm-dev wrote:
>> Here is a last example to illustrate my concern.
>>
>> The problem is about the lowering of node t13.
>>
>> Initial selection DAG: BB#0 '_start:entry'
>>
>> SelectionDAG has 44 nodes:
>>
>>     t11: i16 = Constant<0>
>>
>>                     t0: ch = EntryToken
>>
>>                   t3: ch = llvm.clp.set.rspa t0,
>> TargetConstant:i16<392>, Constant:i32<64>
>>
>> t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>,
>> Constant:i32<64>
>>
>>               t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>,
>> Constant:i32<8>
>>
>>             t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
>> ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0,
>> undef:i16
>>
>>           t16: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t13,
>> ConstantFP:f32<2.000000e+00>, GlobalAddress:i16<float* @x2> 0,
>> undef:i16
>>
>>         t19: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe418>)> t16,
>> ConstantFP:f32<3.000000e+00>, GlobalAddress:i16<float* @x3> 0,
>> undef:i16
>>
>>       t22: ch = store<Volatile ST4[@x4](tbaa=<0x3dbe418>)> t19,
>> ConstantFP:f32<4.000000e+00>, GlobalAddress:i16<float* @x4> 0,
>> undef:i16
>>
>> t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t22,
>> GlobalAddress:i16<float* @x1> 0, undef:i16
>>
>>     t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1,
>> GlobalAddress:i16<float* @x2> 0, undef:i16
>>
>>     t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1,
>> GlobalAddress:i16<float* @x3> 0, undef:i16
>>
>>     t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1,
>> GlobalAddress:i16<float* @x4> 0, undef:i16
>>
>>     t27: i16 = GlobalAddress<float (float, float, float, float)*
>> @fdivfaddfmul_a> 0
>>
>>     t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4>
>>
>>     t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23,
>> FrameIndex:i16<0>,
>> t29:1
>>
>>     t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24,
>> FrameIndex:i16<1>,
>> t31:1
>>
>>     t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25,
>> FrameIndex:i16<2>,
>> t33:1
>>
>>     t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26,
>> FrameIndex:i16<3>,
>> t35:1
>>
>>     t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float
>> (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1
>>
>> t41: ch,glue = callseq_end t39, TargetConstant:i16<4>,
>> TargetConstant:i16<0>, t39:1
>>
>> t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, FrameIndex:i16<0>,
>> t41:1
>>
>>     t43: ch = CLPISD::RET_FLAG t42:1
>>
>> This node is first ‘combined’ into node t51 (bitcast of ConstantFP f32
>> to Constant i32).
>>
>> Combining: t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
>> ConstantFP:f32<1.000000e+00>, GlobalAddress:i16<float* @x1> 0,
>> undef:i16
>>
>> ... into: t51: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
>> Constant:i32<1065353216>, GlobalAddress:i16<float* @x1> 0, undef:i16
>>
>> An a new Constant:i32 node (t50) is created.
>>
>> /The question is: Where in the graph is created this node?/
>>
>> This node seems to be created before the EntryToken !!! Before the
>> initialization of my Stack Pointer registers (RSPA,RSPB,RSPSU).
>>
>> Why isn’t it created between t8 and t51?
>>
>> t0: ch = EntryToken
>>
>>                   t3: ch = llvm.clp.set.rspa t0,
>> TargetConstant:i16<392>, Constant:i32<64>
>>
>>                 t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>,
>> Constant:i32<64>
>>
>>               t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>,
>> Constant:i32<8>
>>
>>             t51: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe418>)> t8,
>> Constant:i32<1065353216>, TargetGlobalAddress:i32<float* @x1> 0,
>> undef:i16
>>
>>           t49: ch = store<Volatile ST4[@x2](tbaa=<0x3dbe418>)> t51,
>> Constant:i32<1073741824>, TargetGlobalAddress:i32<float* @x2> 0,
>> undef:i16
>>
>>         t47: ch = store<Volatile ST4[@x3](tbaa=<0x3dbe418>)> t49,
>> Constant:i32<1077936128>, TargetGlobalAddress:i32<float* @x3> 0,
>> undef:i16
>>
>>       t45: ch = store<Volatile ST4[@x4](tbaa=<0x3dbe418>)> t47,
>> Constant:i32<1082130432>, TargetGlobalAddress:i32<float* @x4> 0,
>> undef:i16
>>
>> t23: f32,ch = load<Volatile LD4[@x1](tbaa=<0x3dbe418>)> t45,
>> TargetGlobalAddress:i32<float* @x1> 0, undef:i16
>>
>>     t24: f32,ch = load<Volatile LD4[@x2](tbaa=<0x3dbe418>)> t23:1,
>> TargetGlobalAddress:i32<float* @x2> 0, undef:i16
>>
>>     t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1,
>> TargetGlobalAddress:i32<float* @x3> 0, undef:i16
>>
>>     t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1,
>> TargetGlobalAddress:i32<float* @x4> 0, undef:i16
>>
>>     t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4>
>>
>>     t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23,
>> TargetFrameIndex:i16<0>, t29:1
>>
>>     t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24,
>> TargetFrameIndex:i16<1>, t31:1
>>
>>     t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25,
>> TargetFrameIndex:i16<2>, t33:1
>>
>>     t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26,
>> TargetFrameIndex:i16<3>, t35:1
>>
>>     t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float
>> (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1
>>
>> t41: ch,glue = callseq_end t39, TargetConstant:i16<4>,
>> TargetConstant:i16<0>, t39:1
>>
>> t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41,
>> TargetFrameIndex:i16<0>, t41:1
>>
>> t43: ch = CLPISD::RET_FLAG t42:1
>>
>> ISEL: Starting pattern match on root node: t50: i32 =
>> Constant<1065353216>
>>
>>     Initial Opcode index to 415
>>
>>     TypeSwitch[i32] from 416 to 432
>>
>> Morphed node: t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216>
>>
>> def: Pat<(f32 fpimm:$imm),
>>
>>                           (MOVSUTO_A_iSLo (bitcast_fpimm_to_i32
>> f32:$imm))>;
>>
>> def: Pat<(i32 imm:$imm),
>>
>>                           (MOVSUTO_A_iSLo (trunc_imm i32:$imm))>;
>>
>> ===== Instruction selection ends:
>>
>> Selected selection DAG: BB#0 '_start:entry'
>>
>> SelectionDAG has 42 nodes:
>>
>>                 t44: i32 = MOVSUTO_A_iSLo
>> TargetConstant:i32<1082130432>
>>
>>                   t46: i32 = MOVSUTO_A_iSLo
>> TargetConstant:i32<1077936128>
>>
>>                     t48: i32 = MOVSUTO_A_iSLo
>> TargetConstant:i32<1073741824>
>>
>> t50: i32 = MOVSUTO_A_iSLo TargetConstant:i32<1065353216>
>>
>> t0: ch = EntryToken
>>
>>                           t3: ch = MOV_SU_iSSs_rspa
>> TargetConstant:i32<64>, t0
>>
>>                         t5: ch = MOV_SU_iSSs_rspb
>> TargetConstant:i32<64>, t3
>>
>>                       t8: ch = MOV_SU_iSSs_rspsu TargetConstant:i32<8>,
>> t5
>>
>>                     t51: ch = MOV_A_or t50,
>> TargetGlobalAddress:i32<float* @x1> 0, t8
>>
>>                   t49: ch = MOV_A_or t48,
>> TargetGlobalAddress:i32<float* @x2> 0, t51
>>
>>                 t47: ch = MOV_A_or t46, TargetGlobalAddress:i32<float*
>> @x3> 0, t49
>>
>>               t45: ch = MOV_A_or t44, TargetGlobalAddress:i32<float*
>> @x4> 0, t47
>>
>> t23: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x1> 0, t45
>>
>>           t24: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x2> 0,
>> t23:1
>>
>>         t25: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x3> 0,
>> t24:1
>>
>>       t26: f32,ch = MOV_A_ro TargetGlobalAddress:i32<float* @x4> 0,
>> t25:1
>>
>>     t29: ch,glue = CALLSEQ_START TargetConstant:i16<4>, t26:1
>>
>>    t31: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
>> TargetGlobalAddress:i32<float* @x1> 0, TargetFrameIndex:i16<0>, t29,
>> t29:1
>>
>>     t33: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
>> TargetGlobalAddress:i32<float* @x2> 0, TargetFrameIndex:i16<1>, t31,
>> t31:1
>>
>>     t35: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
>> TargetGlobalAddress:i32<float* @x3> 0, TargetFrameIndex:i16<2>, t33,
>> t33:1
>>
>>     t37: ch,glue = COPY_TO_CALLEE_A_FROM_GLOBAL
>> TargetGlobalAddress:i32<float* @x4> 0, TargetFrameIndex:i16<3>, t35,
>> t35:1
>>
>>     t39: ch,glue = CALLSEQ TargetGlobalAddress:i16<float (float, float,
>> float, float)* @fdivfaddfmul_a> 0, t37, t37:1
>>
>>     t41: ch,glue = CALLSEQ_END TargetConstant:i16<4>,
>> TargetConstant:i16<0>, t39, t39:1
>>
>>       t42: f32,ch,glue = COPY_TO_CALLER_A TargetFrameIndex:i16<0>, t41,
>> t41:1
>>
>> t43: ch = RET_FLAG t42:1
>>
>> *From:*llvm-dev [mailto:[hidden email]] *On Behalf Of
>> *Dominique Torette via llvm-dev
>> *Sent:* vendredi 4 mai 2018 12:43
>> *To:* [hidden email]
>> *Subject:* [llvm-dev] How to constraint instructions reordering from
>> patterns?
>>
>> Hi,
>>
>> Is there a kind of scope mechanism in the instruction lowering pattern
>> language in order to control where instructions are inserted or how
>> they are later reordered during the SelectionDiag linearization?
>>
>> I know the glue chain that stick instructions together. But such
>> mechanism in not provided in instruction lowering pattern.
>>
>> I’m facing many situations where some patterns are lowered into valid
>> sequences of consecutive SDNodes/Instructions.
>>
>> Such sequences have no glue, so later during Instruction
>> Scheduling/SelectionDiag linearization the instructions are moved out
>> of valid context.
>>
>> Is there some Instruction flags or others features that could delimit
>> the reordering could cross some limit?
>>
>> TIA,        Dominique Torette
>>
>> http://www.spacebel.be/wp-content/uploads/2018/02/image-sign-sbp30y-1.
>> jpg
>>
>> *Dominique Torette*
>> System Architect
>> Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur
>> Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20 www.spacebel.be
>> <http://www.spacebel.be/>
>>
>>
>> ----------------------------------------------------------------------
>> --------
>>
>> E-MAIL DISCLAIMER
>>
>> The present message may contain confidential and/or legally privileged
>> information. If you are not the intended addressee and in case of a
>> transmission error, please notify the sender immediately and destroy
>> this E-mail. Disclosure, reproduction or distribution of this document
>> and its possible attachments is strictly forbidden.
>>
>> SPACEBEL denies all liability for incomplete, improper, inaccurate,
>> intercepted, (partly) destroyed, lost and/or belated transmission of
>> the current information given that unencrypted electronic transmission
>> cannot currently be guaranteed to be secure or error free.
>> Upon request or in conformity with formal, contractual agreements, an
>> originally signed hard copy will be sent to you to confirm the
>> information contained in this E-mail.
>>
>> SPACEBEL denies all liability where E-mail is used for private use.
>>
>> SPACEBEL cannot be held responsible for possible viruses that might
>> corrupt this message and/or your computer system.
>> ----------------------------------------------------------------------
>> ---------
>>
>>
>> ----------------------------------------------------------------------
>> --------
>>
>> E-MAIL DISCLAIMER
>>
>> The present message may contain confidential and/or legally privileged
>> information. If you are not the intended addressee and in case of a
>> transmission error, please notify the sender immediately and destroy
>> this E-mail. Disclosure, reproduction or distribution of this document
>> and its possible attachments is strictly forbidden.
>>
>> SPACEBEL denies all liability for incomplete, improper, inaccurate,
>> intercepted, (partly) destroyed, lost and/or belated transmission of
>> the current information given that unencrypted electronic transmission
>> cannot currently be guaranteed to be secure or error free.
>> Upon request or in conformity with formal, contractual agreements, an
>> originally signed hard copy will be sent to you to confirm the
>> information contained in this E-mail.
>>
>> SPACEBEL denies all liability where E-mail is used for private use.
>>
>> SPACEBEL cannot be held responsible for possible viruses that might
>> corrupt this message and/or your computer system.
>> ----------------------------------------------------------------------
>> ---------
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> https://clicktime.symantec.com/a/1/tbxVxIV7NHJU6POiwH5_tDw_2PbTppHxSRt
>> jhMPVRc8=?d=ALAuPK9uzEDDOpSYAAGYWzyuqN7RRKDngCDIjmR6RSRDIrTp2qQBQqBjQ3
>> ILzf8fK97r5NNx_DkO4WlhMvPy87cqHb6S6izr4tRxwztngStrqoULJ7BvfXEG1f3dBSX3
>> kB4JxllT8TVif5Dp5M-mfh1Xqfd2XxLdTkkCddhqxvYuCrH4VWXYwBJvB_4HM1ZeLVprLg
>> hRH5WMIntD1QbyKdXGArxFb0HvBgGscGE36KGxD0vNFsg3OhCyq7Iyb5JSQAlTgxSA4Xe_
>> EDpBump-g5fSCyrRVAu0q2qtWgIW1uZRKRmOanzj3UE4nr4iqAL9JAaJHLNwYJW6W9jdmo
>> IkmFjH1oqKFguA_uviZrKPLNulEuCLLRfb7yRZWTnaza3I_n7kOSaKaE5Yc9hJsv84M-Kn
>> _kGBySXXHpMz47Ftafa8ZlH1OCtzWSD2whMUAQ%3D%3D&u=http%3A%2F%2Flists.llvm
>> .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://clicktime.symantec.com/a/1/tbxVxIV7NHJU6POiwH5_tDw_2PbTppHxSRtjhMPVRc8=?d=ALAuPK9uzEDDOpSYAAGYWzyuqN7RRKDngCDIjmR6RSRDIrTp2qQBQqBjQ3ILzf8fK97r5NNx_DkO4WlhMvPy87cqHb6S6izr4tRxwztngStrqoULJ7BvfXEG1f3dBSX3kB4JxllT8TVif5Dp5M-mfh1Xqfd2XxLdTkkCddhqxvYuCrH4VWXYwBJvB_4HM1ZeLVprLghRH5WMIntD1QbyKdXGArxFb0HvBgGscGE36KGxD0vNFsg3OhCyq7Iyb5JSQAlTgxSA4Xe_EDpBump-g5fSCyrRVAu0q2qtWgIW1uZRKRmOanzj3UE4nr4iqAL9JAaJHLNwYJW6W9jdmoIkmFjH1oqKFguA_uviZrKPLNulEuCLLRfb7yRZWTnaza3I_n7kOSaKaE5Yc9hJsv84M-Kn_kGBySXXHpMz47Ftafa8ZlH1OCtzWSD2whMUAQ%3D%3D&u=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev
>
>   ------------------------------------------------------------------------------
>
> E-MAIL DISCLAIMER
>
> The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.
>
> SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
> Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.
>
> SPACEBEL denies all liability where E-mail is used for private use.
>
> SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
>   -------------------------------------------------------------------------------
>

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev