thr3ads.net - llvm dev - [LLVMdev] LLVM x86 backend for Intel MIC : trying it out and questions [Jul 2013]

If this information is useful, please help other people find it:
Share via:

Dmitry Mikushin

2013-Jul-11 22:51 UTC

[LLVMdev] LLVM x86 backend for Intel MIC : trying it out and questions

Dear all,

I'm interested to analyse what could be done with current LLVM trunk
to deliver basic Intel MIC support. Let's say, for basic level we'd
want just scalar code execution, no threading, no zmm vectors.
Attached verbose in text, but functionally very simple patch
copy-pastes x86 and x86_64 backends into 32-bit and 64-bit K1OM. In
the end of the message you can find how simple LLVM-generated programs
could be compiled & executed on MIC device, using this patch.

Could you please help finding answers to the following questions:

1) Is there actually a 32-bit mode for MIC? 32-bit ELFs are not
recognized, so...
2) MIC ISA is 32-bit ISA (no SSE/MMX) plus 256-bit AVX-like vectors?
3) If 1 is "no" and 2 is "yes", then does MIC calling
convention
permit generation of programs that use only 32-bit x86 ISA? In other
words, in common case, does calling convention require use of zmm
registers (e.g. return double value) even in scalar programs?

Thanks,
- D.

==
$ cat hello.c
#include <stdio.h>

int main()
{
	printf("Hello, Intel MIC!\n");
	return 0;
}

$ PATH=$PATH:~/rpmbuild/CHROOT/opt/kernelgen/usr/bin clang -emit-llvm
-c hello.c -o - | PATH=$PATH:~/forge/llvm/install/bin/ opt -O3 -S -o
hello.ll
$ cat hello.ll
; ModuleID = '<stdin>'
target datalayout
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@str = private unnamed_addr constant [18 x i8] c"Hello, Intel MIC!\00"

; Function Attrs: nounwind uwtable
define i32 @main() #0 {
entry:
  %puts = tail call i32 @puts(i8* getelementptr inbounds ([18 x i8]*
@str, i64 0, i64 0))
  ret i32 0
}

; Function Attrs: nounwind
declare i32 @puts(i8* nocapture) #1

attributes #0 = { nounwind uwtable
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #1 = { nounwind }

$ PATH=$PATH:~/forge/llvm/install/bin/ llc hello.ll -march=k1om64
-filetype=obj -o hello.mic.o
$ objdump -d hello.mic.o

hello.mic.o:     file format elf64-k1om


Disassembly of section .text:

0000000000000000 <main>:
   0:	55                   	push   %rbp
   1:	48 89 e5             	mov    %rsp,%rbp
   4:	bf 00 00 00 00       	mov    $0x0,%edi
   9:	e8 00 00 00 00       	callq  e <main+0xe>
   e:	31 c0                	xor    %eax,%eax
  10:	5d                   	pop    %rbp
  11:	c3                   	retq

$ icc -mmic hello.mic.o -o hello
x86_64-k1om-linux-ld: error in hello.mic.o(.eh_frame); no
.eh_frame_hdr table will be created.

$ /opt/intel/mic/bin/micnativeloadex ./hello
Hello, Intel MIC!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.k1om.patch
Type: application/octet-stream
Size: 21451 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130712/a8a01a32/attachment.obj>

Demikhovsky, Elena

2013-Jul-12 20:12 UTC

head link

[LLVMdev] LLVM x86 backend for Intel MIC : trying it out and questions

Hello Dmitry,

I'm working on KNL backend and plan to push it to the open source once the
ISA becomes public. We do not plan to support KNC architecture in open source.

-  Elena

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Dmitry Mikushin
Sent: Friday, July 12, 2013 01:51
To: LLVM Developers Mailing List
Subject: [LLVMdev] LLVM x86 backend for Intel MIC : trying it out and questions

Dear all,

I'm interested to analyse what could be done with current LLVM trunk to
deliver basic Intel MIC support. Let's say, for basic level we'd want
just scalar code execution, no threading, no zmm vectors.
Attached verbose in text, but functionally very simple patch copy-pastes x86 and
x86_64 backends into 32-bit and 64-bit K1OM. In the end of the message you can
find how simple LLVM-generated programs could be compiled & executed on MIC
device, using this patch.

Could you please help finding answers to the following questions:

1) Is there actually a 32-bit mode for MIC? 32-bit ELFs are not recognized,
so...
2) MIC ISA is 32-bit ISA (no SSE/MMX) plus 256-bit AVX-like vectors?
3) If 1 is "no" and 2 is "yes", then does MIC calling
convention permit generation of programs that use only 32-bit x86 ISA? In other
words, in common case, does calling convention require use of zmm registers
(e.g. return double value) even in scalar programs?

Thanks,
- D.

==
$ cat hello.c
#include <stdio.h>

int main()
{
	printf("Hello, Intel MIC!\n");
	return 0;
}

$ PATH=$PATH:~/rpmbuild/CHROOT/opt/kernelgen/usr/bin clang -emit-llvm -c hello.c
-o - | PATH=$PATH:~/forge/llvm/install/bin/ opt -O3 -S -o hello.ll $ cat
hello.ll ; ModuleID = '<stdin>'
target datalayout
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@str = private unnamed_addr constant [18 x i8] c"Hello, Intel MIC!\00"

; Function Attrs: nounwind uwtable
define i32 @main() #0 {
entry:
  %puts = tail call i32 @puts(i8* getelementptr inbounds ([18 x i8]* @str, i64
0, i64 0))
  ret i32 0
}

; Function Attrs: nounwind
declare i32 @puts(i8* nocapture) #1

attributes #0 = { nounwind uwtable
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"
"unsafe-fp-math"="false"
"use-soft-float"="false" } attributes #1 = { nounwind }

$ PATH=$PATH:~/forge/llvm/install/bin/ llc hello.ll -march=k1om64 -filetype=obj
-o hello.mic.o $ objdump -d hello.mic.o

hello.mic.o:     file format elf64-k1om


Disassembly of section .text:

0000000000000000 <main>:
   0:	55                   	push   %rbp
   1:	48 89 e5             	mov    %rsp,%rbp
   4:	bf 00 00 00 00       	mov    $0x0,%edi
   9:	e8 00 00 00 00       	callq  e <main+0xe>
   e:	31 c0                	xor    %eax,%eax
  10:	5d                   	pop    %rbp
  11:	c3                   	retq

$ icc -mmic hello.mic.o -o hello
x86_64-k1om-linux-ld: error in hello.mic.o(.eh_frame); no .eh_frame_hdr table
will be created.

$ /opt/intel/mic/bin/micnativeloadex ./hello Hello, Intel MIC!
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Dmitry Mikushin

2013-Jul-12 20:44 UTC

head link

[LLVMdev] LLVM x86 backend for Intel MIC : trying it out and questions

Hello Elena,

Thanks for info! Since Knights Landing (KNL) is going to be shipped
also in form of host CPU, it will have to have open-source support :)
But given that KNL is only announced 1 month ago, we should expect up
to 1.5 years for it to become somewhat wide-spread, i.e. 2014-2015.
Meanwhile, I still hope to perform some KNC evaluation, so answers to
above questions are much appreciated!

Best,
- D.

2013/7/12 Demikhovsky, Elena <elena.demikhovsky at
intel.com>:> Hello Dmitry,
>
> I'm working on KNL backend and plan to push it to the open source once
the ISA becomes public. We do not plan to support KNC architecture in open
source.
>
> -  Elena
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] On Behalf Of Dmitry Mikushin
> Sent: Friday, July 12, 2013 01:51
> To: LLVM Developers Mailing List
> Subject: [LLVMdev] LLVM x86 backend for Intel MIC : trying it out and
questions
>
> Dear all,
>
> I'm interested to analyse what could be done with current LLVM trunk to
deliver basic Intel MIC support. Let's say, for basic level we'd want
just scalar code execution, no threading, no zmm vectors.
> Attached verbose in text, but functionally very simple patch copy-pastes
x86 and x86_64 backends into 32-bit and 64-bit K1OM. In the end of the message
you can find how simple LLVM-generated programs could be compiled & executed
on MIC device, using this patch.
>
> Could you please help finding answers to the following questions:
>
> 1) Is there actually a 32-bit mode for MIC? 32-bit ELFs are not recognized,
so...
> 2) MIC ISA is 32-bit ISA (no SSE/MMX) plus 256-bit AVX-like vectors?
> 3) If 1 is "no" and 2 is "yes", then does MIC calling
convention permit generation of programs that use only 32-bit x86 ISA? In other
words, in common case, does calling convention require use of zmm registers
(e.g. return double value) even in scalar programs?
>
> Thanks,
> - D.
>
> ==>
> $ cat hello.c
> #include <stdio.h>
>
> int main()
> {
>         printf("Hello, Intel MIC!\n");
>         return 0;
> }
>
> $ PATH=$PATH:~/rpmbuild/CHROOT/opt/kernelgen/usr/bin clang -emit-llvm -c
hello.c -o - | PATH=$PATH:~/forge/llvm/install/bin/ opt -O3 -S -o hello.ll $ cat
hello.ll ; ModuleID = '<stdin>'
> target datalayout >
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
> target triple = "x86_64-unknown-linux-gnu"
>
> @str = private unnamed_addr constant [18 x i8] c"Hello, Intel
MIC!\00"
>
> ; Function Attrs: nounwind uwtable
> define i32 @main() #0 {
> entry:
>   %puts = tail call i32 @puts(i8* getelementptr inbounds ([18 x i8]* @str,
i64 0, i64 0))
>   ret i32 0
> }
>
> ; Function Attrs: nounwind
> declare i32 @puts(i8* nocapture) #1
>
> attributes #0 = { nounwind uwtable
"less-precise-fpmad"="false"
> "no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"="true"
> "no-infs-fp-math"="false"
"no-nans-fp-math"="false"
> "unsafe-fp-math"="false"
"use-soft-float"="false" } attributes #1 = { nounwind }
>
> $ PATH=$PATH:~/forge/llvm/install/bin/ llc hello.ll -march=k1om64
-filetype=obj -o hello.mic.o $ objdump -d hello.mic.o
>
> hello.mic.o:     file format elf64-k1om
>
>
> Disassembly of section .text:
>
> 0000000000000000 <main>:
>    0:   55                      push   %rbp
>    1:   48 89 e5                mov    %rsp,%rbp
>    4:   bf 00 00 00 00          mov    $0x0,%edi
>    9:   e8 00 00 00 00          callq  e <main+0xe>
>    e:   31 c0                   xor    %eax,%eax
>   10:   5d                      pop    %rbp
>   11:   c3                      retq
>
> $ icc -mmic hello.mic.o -o hello
> x86_64-k1om-linux-ld: error in hello.mic.o(.eh_frame); no .eh_frame_hdr
table will be created.
>
> $ /opt/intel/mic/bin/micnativeloadex ./hello Hello, Intel MIC!
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>

Possibly Parallel Threads

Search for more possibly parallel threads

llvm dev - Jul 2013 - [LLVMdev] LLVM x86 backend for Intel MIC : trying it out and questions

[LLVMdev] LLVM x86 backend for Intel MIC : trying it out and questions

[LLVMdev] LLVM x86 backend for Intel MIC : trying it out and questions

[LLVMdev] LLVM x86 backend for Intel MIC : trying it out and questions

Possibly Parallel Threads