• Next Thread Prev Thread

• Posts   Search Threads

• srimks April 25, 2009 6:50 PM PDT    Vectorization - pragma asm interpretation Hello, Simply looking to interpret below things - (a) For multiple C++ package file, when I do vectorizations (calling of pragma's) within that file within section of code, I get starting and ending asm as - { 44d960:                      55                                  push %rbp 44d961:                      48 83 ec 50                     sub $0x50,%rsp 44d965:                      49 89 f0                          mov %rsi,%r8 44d968:                      4c 63 c9                          movslq %ecx,%r9 ... ... 44dc84:                       48 83 c4 50                     add $0x50,%rsp 44dc88:                       5d                                  pop %rbp 44dc89:                       c3                                  retq 44dc8a:                       90                                  nop 44dc8b:                       48 8d 74 26 00                lea 0x0(%rsi),%rsi } (b) But the same code w/o using any pragma's call, the starting & ending asm are as - { 44d960:                       48 83 ec 68                     sub $0x68,%rsp 44d964:                       49 89 f9                          mov %rdi,%r9 44d967:                       49 89 d0                         mov %rdx,%r8 44d96a:                       4c 63 d1                         movslq %ecx,%r10 .. .. .. 44dc4e:                        48 83 c4 68                    add $0x68,%rsp 44dc52:                        c3                                 retq 44dc53:                        90                                 nop 44dc54:                        48 8d 74 26 00               lea 0x0(%rsi),%rsi 44dc59:                        48 8d bf 00 00 00 00       lea 0x0(%rdi),%rdi } --- Query: (1) Could the difference between having PUSH/POP call with pragma vectorization calls and not having w/o it be differentiated? (2) W/o pragma calls, the asm in (b) has "lea" calls twice and also the during starting it has - sub, mov, mov & movslq than with pragma calls, why pragma calls bring such a difference? ~BR Igor Levicki April 25, 2009 10:19 PM PDT Rate   #1 Re: Vectorization - pragma asm interpretation Two LEA instructions at the function end are simply fillers (NOPs) to ensure proper alignment for the next function -- they aren't part of the function epilogue. As for the prologue difference it is hard to tell without seeing the rest of the surrounding code. Most likely vectorization enables the compiler to "see" an opportunity for some other optimizations thus resulting in a bit shorter code which uses less variables. -- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you. srimks April 26, 2009 8:57 AM PDT Rate   #2 Reply To #1 Re: Vectorization - pragma asm interpretation Quoting - Igor Levicki Two LEA instructions at the function end are simply fillers (NOPs) to ensure proper alignment for the next function -- they aren't part of the function epilogue. As for the prologue difference it is hard to tell without seeing the rest of the surrounding code. Most likely vectorization enables the compiler to "see" an opportunity for some other optimizations thus resulting in a bit shorter code which uses less variables. yeah, you are right for epilogue, code-generators normally generates NOP (no-operation) instructions to align instructions. Lets look for prologue part if possible. Thanks Igor. ~BR srimks April 28, 2009 10:45 PM PDT Rate   #3 Reply To #1 Re: Vectorization - pragma asm interpretation Quoting - Igor Levicki Two LEA instructions at the function end are simply fillers (NOPs) to ensure proper alignment for the next function -- they aren't part of the function epilogue. As for the prologue difference it is hard to tell without seeing the rest of the surrounding code. Most likely vectorization enables the compiler to "see" an opportunity for some other optimizations thus resulting in a bit shorter code which uses less variables. As qouted "As for the prologue difference it is hard to tell without seeing the rest of the surrounding code. Most likely vectorization enables the compiler to "see" an opportunity for some other optimizations thus resulting in a bit shorter code which uses less variables.", probably iif you see prologues of both - (a) Prologue with pragma vectorization - { 44d960:                      55                                    push %rbp 44d961:                      48 83 ec 50                     sub $0x50,%rsp 44d965:                      49 89 f0                           mov %rsi,%r8 44d968:                      4c 63 c9                          movslq %ecx,%r9 ... ... } (b) The same code w/o using any pragma's call, the prologue asm are as - { 44d960:                       48 83 ec 68                     sub $0x68,%rsp 44d964:                       49 89 f9                           mov %rdi,%r9 44d967:                       49 89 d0                          mov %rdx,%r8 44d96a:                       4c 63 d1                          movslq %ecx,%r1 ... ... } With above (a) i.e with pragma, the "PUSH %RBP" instructions is internally split into two micro-operations which can be represented as  "SUB  RSP, 4" and "MOV  [RDI], %r9" . The advantage of this is that the "SUB RSP, 4" micro-operation can be executed even if the vale of RBP is not ready yet. I don't think much gain can be obtained with both the prologues with and w/o pragma vectorization, their meanings are same, the only important factor which makes a difference is having "lea" instructions twice for alignment with pragma call of vectorization. But the questions arises - why the "sub $0x68,%rsp" & "mov %rdi,%r9" w/o pragma have been replaced with single "push %rbp"? is it becoz "push %rbp" has better latency and reciprocal throughput. ~BR

• = Best Answer

  Next Thread Prev Thread

Intel Software Network Forums Statistics

17,025 users have contributed to 48,319 threads and 172,758 posts to date.

For more complete information about compiler optimizations, see our Optimization Notice.