<font size=2 face="sans-serif">Hal,</font>
<br>
<br><font size=2 face="sans-serif">I noticed that your latest code drop
(r188410-20130814) contain older patches for clang/llvm/compiler-rt ..
is this intentional? </font>
<br>
<br><font size=2 face="sans-serif">$ tar tzf r188410-20130814-files.tar.gz
| grep patch</font>
<br><font size=2 face="sans-serif">r188410-20130814-files/clang-bgq-r186563-20130718.patch</font>
<br><font size=2 face="sans-serif">r188410-20130814-files/llvm-bgq-r186563-20130718.patch</font>
<br><font size=2 face="sans-serif">r188410-20130814-files/compiler-rt-bgq-r186563-20130718.patch</font>
<br>
<br><font size=2 face="sans-serif">I did a rebuild and found that the cnk
syscall fix - described below - wasn't there. Is this due to the "old"
patches?</font>
<br>
<br><font size=2 face="sans-serif"><br>
Michael Blocksome<br>
Blue Gene Messaging<br>
blocksom@us.ibm.com<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Hal Finkel <hfinkel@anl.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">Michael Blocksome/Rochester/IBM@IBMUS,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:      
 </font><font size=1 face="sans-serif">llvm-bgq-discuss@lists.alcf.anl.gov</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">08/03/2013 07:44 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [Llvm-bgq-discuss]
clang code gen error -- Kernel_RanksToCoords</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>----- Original Message -----<br>
> <br>
> Hal,<br>
> <br>
> Tom and I have discovered what appears to be a code gen problem when<br>
> compiling the Kernel_RanksToCoords() CNK syscall. See Tom's analysis<br>
> below.<br>
<br>
Thanks! (and thank Tom). Because of the way that LLVM internally names
its registers, this needed some additional special handling in the PPC
backend. I've fixed this upstream (in r187693) (and so will be included
in the next rebase, although this change should trivially apply to the
current patchset version as well).<br>
<br>
> <br>
> GPR4 receives the second parameter, GPR5 receives the third<br>
> parameter, and GPR3 is the return value.<br>
> <br>
> ---<br>
> <br>
> BTW, I'm using the latest "bgclang" wrapper script, but
I've renamed<br>
> it to powerpc64-bgq-linux-clang so it plays nice with autoconf.<br>
<br>
This is a good idea, thanks! I've added these symlinks here as well.<br>
<br>
 -Hal<br>
<br>
> <br>
> <br>
> Michael Blocksome<br>
> Blue Gene Messaging<br>
> blocksom@us.ibm.com<br>
> <br>
> ----- Forwarded by Michael Blocksome/Rochester/IBM on 07/26/2013<br>
> 01:20 PM -----<br>
> <br>
> From: Thomas Gooding/Rochester/IBM<br>
> To: Michael Blocksome/Rochester/IBM@IBMUS,<br>
> Date: 07/26/2013 11:20 AM<br>
> Subject: Re: clang<br>
> <br>
> <br>
> <br>
> Looks like the addresses are getting truncated to 32-bits.<br>
> <br>
> after ... Kernel_RanksToCoords (8, 0x1dbfffba18 , 0x1dbfffba10 {0})
=<br>
> 14<br>
> <br>
> {4}.16.1: TB=0000000773c39a5c FL_SYSCALLAT:0 Syscall 1055 at<br>
> IP=0x0000000001001314 LR=0x00000000010012bc SP=0x0000001dbfffb9a0<br>
> (RANKS2COORDS)<br>
> {4}.16.1: TB=0000000773c39acc FL_SYSCALLEN:0 Syscall Entry<br>
> GPR3=0x0000000000000008 GPR4= 0x00000000bfffba18 GPR5=<br>
> 0x00000000bfffba10 GPR6=0x0000001dbfffba50<br>
> {4}.16.1: TB=0000000773c3a1a4 FL_SYSCALLRT:0 Syscall Return GPR3=<br>
> 0x000000000000000e<br>
> <br>
> <br>
> 10012c0: 38 60 04 1f li r3,1055<br>
> 10012c4: 38 9f 00 a8 addi r4,r31,168<br>
> 10012c8: 38 df 00 b0 addi r6,r31,176<br>
> 10012cc: 38 ff 00 b8 addi r7,r31,184<br>
> 10012d0: 39 1f 00 c0 addi r8,r31,192<br>
> 10012d4: e8 bf 00 80 ld r5,128(r31) <---- quite a few load/stores...<br>
> seems very wasteful.<br>
> 10012d8: fb df 00 d0 std r30,208(r31)<br>
> 10012dc: fb bf 00 c8 std r29,200(r31)<br>
> 10012e0: e9 3f 00 d0 ld r9,208(r31)<br>
> 10012e4: e9 5f 00 c8 ld r10,200(r31)<br>
> 10012e8: f8 bf 00 d8 std r5,216(r31)<br>
> 10012ec: e8 bf 00 d8 ld r5,216(r31)<br>
> 10012f0: f9 3f 00 b0 std r9,176(r31)<br>
> 10012f4: f9 5f 00 a8 std r10,168(r31)<br>
> 10012f8: f8 bf 00 b8 std r5,184(r31)<br>
> 10012fc: f8 7f 00 c0 std r3,192(r31)<br>
> 1001300: 80 a4 00 04 lwz r5,4(r4) <---- these are 32-bit loads,<br>
> should be 64-bit.<br>
> 1001304: 80 86 00 04 lwz r4,4(r6)<br>
> 1001308: 80 67 00 04 lwz r3,4(r7)<br>
> 100130c: 80 08 00 04 lwz r0,4(r8)<br>
> 1001310: 44 00 00 02 sc<br>
> <br>
> <br>
> The inline assembly piece is:<br>
> #define CNK_SPI_SYSCALL_3(name, arg0, arg1, arg2) \<br>
> ({ \<br>
> register uint64_t r0 __asm__ ("r0") = (__NR_ ## name); \<br>
> register uint64_t r3 __asm__ ("r3") = ((uint64_t) (arg0));
\<br>
> register uint64_t r4 __asm__ ("r4") = ((uint64_t) (arg1));
\<br>
> register uint64_t r5 __asm__ ("r5") = ((uint64_t) (arg2));
\<br>
> __asm__ __volatile__ \<br>
> ("sc" \<br>
> : "=&r"(r0),"=&r"(r3),"=&r"(r4),"=&r"(r5)
\<br>
> : "0"(r0), "1"(r3), "2"(r4), "3"(r5)
\<br>
> : "r6","r7","r8","r9","r10","r11","r12","cr0","memory");
\<br>
> r3; \<br>
> })<br>
> <br>
> I don't see where they would be interpreted as 32-bits. In the<br>
> input/outputs section, "r" is a register for gcc assembly,
which<br>
> should be 64-bit for a 64-bit compile. I presume LLVM is following<br>
> gcc assembly semantics.<br>
> <br>
> The other comment was that Hal seems to be directing people to his<br>
> "bgclang" wrapper script. I'm not sure it will make a difference,<br>
> but could be something to try.<br>
> <br>
> Tom<br>
> <br>
> Tom Gooding<br>
> Senior Engineer / Blue Gene Kernels<br>
> 507-253-0747 (internal: 553-0747)<br>
> <br>
> <br>
> <br>
>                  From:
                 Michael
Blocksome/Rochester/IBM<br>
>                  To:
                 Thomas
Gooding/Rochester/IBM@IBMUS,<br>
>                  Date:
                 07/26/2013
08:56 AM<br>
>                  Subject:
                 clang<br>
> <br>
> <br>
> <br>
> Tom,<br>
> <br>
> I wrote a very simple test and compiled with the latest version of<br>
> llvm/clang from Hal.<br>
> <br>
> $ cat kernel_rankstocoords.c<br>
> <br>
> #include <stdlib.h><br>
> #include <stdio.h><br>
> #include <stdint.h><br>
> <br>
> #include "kernel/location.h"<br>
> <br>
> <br>
> int main (int argc, char * argv[])<br>
> {<br>
> uint32_t rc = 1;<br>
> size_t mapsize = 2*sizeof(BG_CoordinateMapping_t);<br>
> BG_CoordinateMapping_t map[2];<br>
> uint64_t n = 0;<br>
> <br>
> fprintf (stdout, "before .. Kernel_RanksToCoords (%zu, %p, %p
{%lu})<br>
> = %d\n", mapsize, map, &n, n, rc);<br>
> rc = Kernel_RanksToCoords (mapsize, map, &n);<br>
> fprintf (stdout, "after ... Kernel_RanksToCoords (%zu, %p, %p
{%lu})<br>
> = %d\n", mapsize, map, &n, n, rc);<br>
> <br>
> return 0;<br>
> }<br>
> <br>
> $<br>
> /bghome/blocksom/development/c++11/install/powerpc64-bgq-linux-clang<br>
> kernel_rankstocoords.c -o kernel_rankstocoords.clang<br>
> -I/bgsys/drivers/ppcfloor/spi/include<br>
> -I/bgsys/drivers/ppcfloor/spi/include/kernel/cnk<br>
> -I/bgsys/drivers/ppcfloor<br>
> <br>
> <br>
> When I run this I get that same error as when I ran pami compiled<br>
> with clang..<br>
> <br>
> $ runjob --block R00-M1-N10 --np 2 : kernel_rankstocoords.clang<br>
> before .. Kernel_RanksToCoords (8, 0x1dbfffba18, 0x1dbfffba10 {0})
=<br>
> 1<br>
> before .. Kernel_RanksToCoords (8, 0x1dbfffba18, 0x1dbfffba10 {0})
=<br>
> 1<br>
> after ... Kernel_RanksToCoords (8, 0x1dbfffba18, 0x1dbfffba10 {0})
=<br>
> 14<br>
> after ... Kernel_RanksToCoords (8, 0x1dbfffba18, 0x1dbfffba10 {0})
=<br>
> 14<br>
> <br>
> .. but it runs fine when compiled with gcc..<br>
> <br>
> $ /bgsys/drivers/ppcfloor/gnu-linux/bin/powerpc64-bgq-linux-gcc<br>
> kernel_rankstocoords.c -o kernel_rankstocoords.gcc<br>
> -I/bgsys/drivers/ppcfloor/spi/include<br>
> -I/bgsys/drivers/ppcfloor/spi/include/kernel/cnk<br>
> -I/bgsys/drivers/ppcfloor<br>
> <br>
> $ runjob --block R00-M1-N10 --np 2 : kernel_rankstocoords.gcc<br>
> before .. Kernel_RanksToCoords (8, 0x1dbfffba54, 0x1dbfffba60 {0})
=<br>
> 1<br>
> before .. Kernel_RanksToCoords (8, 0x1dbfffba54, 0x1dbfffba60 {0})
=<br>
> 1<br>
> after ... Kernel_RanksToCoords (8, 0x1dbfffba54, 0x1dbfffba60 {2})
=<br>
> 0<br>
> after ... Kernel_RanksToCoords (8, 0x1dbfffba54, 0x1dbfffba60 {2})
=<br>
> 0<br>
> <br>
> <br>
> Any ideas? Is it something I'm doing wrong, or should I post this
to<br>
> the llvm-bgq mailing list?<br>
> <br>
> <br>
> Michael Blocksome<br>
> Blue Gene Messaging<br>
> blocksom@us.ibm.com<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> llvm-bgq-discuss mailing list<br>
> llvm-bgq-discuss@lists.alcf.anl.gov<br>
> </font></tt><a href="https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss"><tt><font size=2>https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss</font></tt></a><tt><font size=2><br>
> <br>
<br>
-- <br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
</font></tt>
<br>