Software Archive
Read-only legacy content
17061 Discussions

Labels in inline asm, error of compilation

Elizaveta_G_
Beginner
3,558 Views
 

I try to make inline asm in C code for MIC (Intel Xeon Phi). And I have a problem with instruction jknzd.

This is a fragment of my code:

   float *A = (float*)_mm_malloc(N * sizeof(float), 64);
   int32_t* Indx = (int32_t*)_mm_malloc(N * sizeof(int32_t), 64);

   __m512i idx = __cdecl _mm512_load_epi32(&Indx[i]);
   asm (
          "kxnor %%k1, %%k1\n\t"
          "1:" "vgatherpf0dps (%0, %1, 4){{%%k1}}\n\t"
          "jknzd 1b, %%k1"
          :   
          :"r"(A),"x"(idx)
          :"%r8d", "%k1"
   );  

Compiler is icc-13.0.1, options: -mmic -lrt -O3. When I try to compile, I get this message:

/tmp/icc1XDD1vas_.s: Assembler messages: /tmp/icc1XDD1vas_.s:237: Error: invalid char '{' beginning operand 1 {rz-sae}' /tmp/icc1XDD1vas_.s:250: Error: invalid char '{' beginning operand 1{rn-sae}' /tmp/icc1XDD1vas_.s:254: Error: invalid char '{' beginning operand 1 {rn-sae}' /tmp/icc1XDD1vas_.s:260: Error: invalid char '{' beginning operand 1{rn-sae}' /tmp/icc1XDD1vas_.s:263: Error: invalid char '{' beginning operand 1 {rn-sae}' /tmp/icc1XDD1vas_.s:264: Error: invalid char '{' beginning operand 1{rn-sae}' /tmp/icc1XDD1vas_.s:360: Error: invalid char '{' beginning operand 1 {rz-sae}' /tmp/icc1XDD1vas_.s:373: Error: invalid char '{' beginning operand 1{rn-sae}' /tmp/icc1XDD1vas_.s:375: Error: invalid char '{' beginning operand 1 {rn-sae}' /tmp/icc1XDD1vas_.s:378: Error: invalid char '{' beginning operand 1{rn-sae}' /tmp/icc1XDD1vas_.s:383: Error: invalid char '{' beginning operand 1 {rn-sae}' /tmp/icc1XDD1vas_.s:385: Error: invalid char '{' beginning operand 1{rn-sae}' /tmp/icc1XDD1vas_.s:398: Error: invalid char '{' beginning operand 1 {rz-sae}' /tmp/icc1XDD1vas_.s:402: Error: invalid char '{' beginning operand 1{rn-sae}' /tmp/icc1XDD1vas_.s:415: Error: invalid char '{' beginning operand 1 {rn-sae}' /tmp/icc1XDD1vas_.s:417: Error: invalid char '{' beginning operand 1{rn-sae}' /tmp/icc1XDD1vas_.s:421: Error: invalid char '{' beginning operand 1 {rn-sae}' /tmp/icc1XDD1vas_.s:422: Error: invalid char '{' beginning operand 1{rn-sae}'

If there is a simple jump, like "jmp 1b" it's ok. What am I doing wrong?

0 Kudos
1 Solution
Kevin_D_Intel
Employee
3,558 Views

This may relate to a known defect in the assembler (and objdump) from an earlier bintuils release (distributed with MPSS 2.1). You noted using an earlier icc 13.0.1 so you may also be using an earlier MPSS 2.1 release.

There was defect with the assembler distributed in the buntils component in the MPSS 2.1.3126-14 release timeframe where the assembler and objdump did not accept some valid mnemonics used by the compiler.

From an associated internal defect reported against the compiler (DPD200241496) , the issue reported was described as:

Inline code fails on native compiler as shown in the following example:

$ icc -mmic -c -O1 report2.c
/tmp/icc2eDt1Bas_.s: Assembler messages:
/tmp/icc2eDt1Bas_.s:78: Error: invalid char '{' beginning operand 1 `{rz-sae}'
/tmp/icc2eDt1Bas_.s:91: Error: invalid char '{' beginning operand 1 `{rn-sae}'
/tmp/icc2eDt1Bas_.s:94: Error: invalid char '{' beginning operand 1 `{rn-sae}'
/tmp/icc2eDt1Bas_.s:98: Error: invalid char '{' beginning operand 1 `{rn-sae}'
/tmp/icc2eDt1Bas_.s:104: Error: invalid char '{' beginning operand 1 `{rn-sae}'
/tmp/icc2eDt1Bas_.s:106: Error: invalid char '{' beginning operand 1 `{rn-sae}'
The customer goes on to say:  I believe this has something to do with the use of global labels in the inline assembly.  If they are replaced by local labels then the problem disappears.

The compiler developers identified the issue as one with the assembler and objdump and filed an internal defect (HSD# 4117584) (against binutils) where the summary was:

According to the KNC EAS, the assembler mnemonics for Static Rounding Mode and Suppress All Exceptions (SAE) should be:
  Round To Nearest (even) with SAE         , {rn-sae}
  Round Down (-INF) with SAE               , {rd-sae}
  Round Up (+INF) with SAE                 , {ru-sae}
  Round Toward Zero with SAE               , {rz-sae}
  SAE                                      , {sae}
However, the assembler and objdump do not accept such mnemonics. Instead, they accept something like this: {rn}{sae}, which does not correspond to the EAS.

This defect was fixed in the assembler and objdump in a later MPSS release. According to the internal defect (HSD# 4117584) this was fixed in after the MPSS version 2.1.5889-14.

I believe these internal reports relate to John’s post here where he offers a sed script to repair the affected assembly.

View solution in original post

0 Kudos
7 Replies
James_C_Intel2
Employee
3,558 Views

If you compile with -S you should then be able to look at the assembler code (and can feed it to the assembler by hand), which may make things more obvious.

0 Kudos
Elizaveta_G_
Beginner
3,558 Views

James Cownie (Intel) wrote:

If you compile with -S you should then be able to look at the assembler code (and can feed it to the assembler by hand), which may make things more obvious.

Thaks for your reply,  it was the first thing that I did. I added intrinsic __cdecl _mm512_prefetch_i32gather_ps(idx, A, 4, _MM_HINT_T0) to my code and compiled it with -S option. And after that I added some lines to my asm inline.

This is a fragment of intrinsic from assembler code (with option -S):

..B1.45:                        # Preds ..B1.45 ..B1.44 Latency 21
        vmovdqa32 (%rdx), %zmm0                                 #73.31 c1
        vprefetch1 1024(%rdx)                                   #71.13 c1
        kxnor     %k1, %k1                                      #74.25 c5
        vprefetch0 128(%rdx)                                    #71.13 c5
..L35:                                                          #74.25
        vgatherpf0dps (%rsi,%zmm0,4){%k1}                   #74.25
        jknzd     ..L35, %k1    # Prob 50%                      #74.25

So I just want to understand how to make labels if i use jknzd.

0 Kudos
James_C_Intel2
Employee
3,558 Views

That looks different from the code I would expect from your asm, in that it has only {%k1} on the vgather op, whereas your quoted asm appears to generate {{%k1}}. Since the complaint from the assembler was about an invalid '{' that might be relevant.

I just want to understand how to make labels if i use jknzd

I don't think your problem has anything to do with labels... I think it's bad syntax elsewhere.

0 Kudos
Elizaveta_G_
Beginner
3,558 Views

James Cownie (Intel) wrote:

That looks different from the code I would expect from your asm, in that it has only {%k1} on the vgather op, whereas your quoted asm appears to generate {{%k1}}. Since the complaint from the assembler was about an invalid '{' that might be relevant.

I just want to understand how to make labels if i use jknzd

I don't think your problem has anything to do with labels... I think it's bad syntax elsewhere.

I guess in AT&T there must be double {{ with mask. If i compile my inline asm with -S, I get this:

..B1.45:                        # Preds ..B1.45 ..B1.44 Latency 9
        vmovdqa32 (%rcx,%r13), %zmm0                            #73.31 c1
        addq      $16, %rsi                                     #71.45 c1
# Begin ASM
        kxnor %k1, %k1
    1:vgatherpf0dps (%rdi, %zmm0, 4){%k1}
    jknzd 1b, %k1

# End ASM                                                       #75.0

So there is no problem with {{ around k1.

Yes, I also think that the problem is with syntax. But I think that I use labels (or jknzd) wrong. Because without jknzd everything is alright.

0 Kudos
Kevin_D_Intel
Employee
3,559 Views

This may relate to a known defect in the assembler (and objdump) from an earlier bintuils release (distributed with MPSS 2.1). You noted using an earlier icc 13.0.1 so you may also be using an earlier MPSS 2.1 release.

There was defect with the assembler distributed in the buntils component in the MPSS 2.1.3126-14 release timeframe where the assembler and objdump did not accept some valid mnemonics used by the compiler.

From an associated internal defect reported against the compiler (DPD200241496) , the issue reported was described as:

Inline code fails on native compiler as shown in the following example:

$ icc -mmic -c -O1 report2.c
/tmp/icc2eDt1Bas_.s: Assembler messages:
/tmp/icc2eDt1Bas_.s:78: Error: invalid char '{' beginning operand 1 `{rz-sae}'
/tmp/icc2eDt1Bas_.s:91: Error: invalid char '{' beginning operand 1 `{rn-sae}'
/tmp/icc2eDt1Bas_.s:94: Error: invalid char '{' beginning operand 1 `{rn-sae}'
/tmp/icc2eDt1Bas_.s:98: Error: invalid char '{' beginning operand 1 `{rn-sae}'
/tmp/icc2eDt1Bas_.s:104: Error: invalid char '{' beginning operand 1 `{rn-sae}'
/tmp/icc2eDt1Bas_.s:106: Error: invalid char '{' beginning operand 1 `{rn-sae}'
The customer goes on to say:  I believe this has something to do with the use of global labels in the inline assembly.  If they are replaced by local labels then the problem disappears.

The compiler developers identified the issue as one with the assembler and objdump and filed an internal defect (HSD# 4117584) (against binutils) where the summary was:

According to the KNC EAS, the assembler mnemonics for Static Rounding Mode and Suppress All Exceptions (SAE) should be:
  Round To Nearest (even) with SAE         , {rn-sae}
  Round Down (-INF) with SAE               , {rd-sae}
  Round Up (+INF) with SAE                 , {ru-sae}
  Round Toward Zero with SAE               , {rz-sae}
  SAE                                      , {sae}
However, the assembler and objdump do not accept such mnemonics. Instead, they accept something like this: {rn}{sae}, which does not correspond to the EAS.

This defect was fixed in the assembler and objdump in a later MPSS release. According to the internal defect (HSD# 4117584) this was fixed in after the MPSS version 2.1.5889-14.

I believe these internal reports relate to John’s post here where he offers a sed script to repair the affected assembly.

0 Kudos
Elizaveta_G_
Beginner
3,558 Views

Kevin Davis, Thank you very much for such a detailed reply! I've used the script and everything compiles now.

0 Kudos
Kevin_D_Intel
Employee
3,558 Views

Excellent!  I am really happy to hear that helped.

0 Kudos
Reply