<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt"><div><span>Has anyone worked with or used the LLVM backend or compiler for Haskell ??</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span>David</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px;
font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div class="yahoo_quoted" style="display: block;"> <br> <br> <div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"> <div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"> <div dir="ltr"> <font size="2" face="Arial"> On Monday, October 21, 2013 5:26 PM, "llvmdev-request@cs.uiuc.edu" <llvmdev-request@cs.uiuc.edu> wrote:<br> </font> </div> <div class="y_msg_container">Send LLVMdev mailing list submissions to<br> <a
ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>or, via email, send a message with subject or body 'help' to<br> <a ymailto="mailto:llvmdev-request@cs.uiuc.edu" href="mailto:llvmdev-request@cs.uiuc.edu">llvmdev-request@cs.uiuc.edu</a><br><br>You can reach the person managing the list at<br> <a ymailto="mailto:llvmdev-owner@cs.uiuc.edu" href="mailto:llvmdev-owner@cs.uiuc.edu">llvmdev-owner@cs.uiuc.edu</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of LLVMdev digest..."<br><br><br>Today's Topics:<br><br> 1. Re: Bug #16941 (Dmitry Babokin)<br> 2. Re: Bug #16941 (Nadav Rotem)<br> 3. Re:
Feature request for include llvm-mc in llvm.org/builds<br> (Reid Kleckner)<br> 4. Re: Feature request for include llvm-mc in llvm.org/builds<br> (Reid Kleckner)<br> 5. Re: Bug #16941 (Dmitry Babokin)<br> 6. Re: First attempt at recognizing pointer reduction<br> (Arnold Schwaighofer)<br> 7. [lld] Handle _GLOBAL_OFFSET_TABLE symbol (Simon Atanasyan)<br> 8. Re: [lld] Handle _GLOBAL_OFFSET_TABLE symbol (Shankar Easwaran)<br> 9. Re: First attempt at recognizing pointer reduction (Renato Golin)<br> 10. Re: [lld] Handle _GLOBAL_OFFSET_TABLE symbol (Simon Atanasyan)<br> 11. Re: First attempt at recognizing pointer reduction<br> (Arnold Schwaighofer)<br> 12. Re: [lld] Handle _GLOBAL_OFFSET_TABLE symbol (Shankar Easwaran)<br> 13. Re: llvm.org bug trend (Robinson,
Paul)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Mon, 21 Oct 2013 22:12:07 +0400<br>From: Dmitry Babokin <<a ymailto="mailto:babokin@gmail.com" href="mailto:babokin@gmail.com">babokin@gmail.com</a>><br>To: Nadav Rotem <<a ymailto="mailto:nrotem@apple.com" href="mailto:nrotem@apple.com">nrotem@apple.com</a>><br>Cc: Ilia Filippov <<a ymailto="mailto:ili.filippov@gmail.com" href="mailto:ili.filippov@gmail.com">ili.filippov@gmail.com</a>>, LLVM Developers Mailing<br> List <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] Bug #16941<br>Message-ID:<br> <CACRFwuiGHNo_QdX_Ty+<a ymailto="mailto:gij4PzHhMyyzpvm-2Lco0gdqNXSw8LQ@mail.gmail.com"
href="mailto:gij4PzHhMyyzpvm-2Lco0gdqNXSw8LQ@mail.gmail.com">gij4PzHhMyyzpvm-2Lco0gdqNXSw8LQ@mail.gmail.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>Nadav,<br><br>You are absolutely right, it's ISPC workload. I've checked SSE4 and it's<br>also severely affected.<br><br>We use intrinsics only for conversion <N x i32> <=> i32, i.e. movmsk.ps.<br>For the rest we use general LLVM instructions. And I actually would really<br>like to stick this way. We rely on LLVM's ability to produce efficient code<br>from general LLVM IR. Relying on intrinsics too much would be a crunch and<br>a path to nowhere for many reasons :)<br><br>What is the reason for this transformation, if it doesn't lead to efficient<br>code?<br><br>Dmitry.<br><br><br><br>On Mon, Oct 21, 2013 at 7:01 PM, Nadav Rotem <<a ymailto="mailto:nrotem@apple.com" href="mailto:nrotem@apple.com">nrotem@apple.com</a>> wrote:<br><br>> Hi Dmitry.<br>><br>>
This looks like an ISPC workload. ISPC works around a limitation in<br>> selection dag which does not know how to legalize mask types when both 128<br>> and 256 bit registers are available. ISPC works around this problem by<br>> expanding the mask to i32s and using intrinsics. Can you please verify that<br>> this regression only happens on AVX ? Can you change ISPC to use intrinsics<br>> ?<br>><br>> Thanks<br>> Nadav<br>><br>> Sent from my iPhone<br>><br>> > On Oct 21, 2013, at 4:04, Dmitry Babokin <<a ymailto="mailto:babokin@gmail.com" href="mailto:babokin@gmail.com">babokin@gmail.com</a>> wrote:<br>> ><br>> > Nadav,<br>> ><br>> > Could you please have a look at bug #16941 and let us know what you<br>> think about it? It's performance regression after one of your commits.<br>> ><br>> > Thanks.<br>> ><br>> > Dmitry.<br>><br>-------------- next part
--------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/83d77e1f/attachment-0001.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/83d77e1f/attachment-0001.html</a>><br><br>------------------------------<br><br>Message: 2<br>Date: Mon, 21 Oct 2013 11:18:46 -0700<br>From: Nadav Rotem <<a ymailto="mailto:nrotem@apple.com" href="mailto:nrotem@apple.com">nrotem@apple.com</a>><br>To: Dmitry Babokin <<a ymailto="mailto:babokin@gmail.com" href="mailto:babokin@gmail.com">babokin@gmail.com</a>><br>Cc: Ilia Filippov <<a ymailto="mailto:ili.filippov@gmail.com" href="mailto:ili.filippov@gmail.com">ili.filippov@gmail.com</a>>, LLVM Developers Mailing<br> List <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] Bug
#16941<br>Message-ID: <<a ymailto="mailto:567CDFA6-9E85-4943-869C-1C471B2143D8@apple.com" href="mailto:567CDFA6-9E85-4943-869C-1C471B2143D8@apple.com">567CDFA6-9E85-4943-869C-1C471B2143D8@apple.com</a>><br>Content-Type: text/plain; charset="us-ascii"<br><br>Hi Dmitry, <br><br>ISPC does some instruction selection as part of vectorization (on ASTs!) by placing intrinsics for specific operations. The SEXT to i32 pattern was implemented because LLVM did not support vector-selects when this code was written. <br><br>Can you submit a small SSE4 test case that demonstrates the problem? Select is the canonical form of this operations, and SEXT is usually more difficult to lower. <br><br>Thanks,<br>Nadav<br><br>On Oct 21, 2013, at 11:12 AM, Dmitry Babokin <<a ymailto="mailto:babokin@gmail.com" href="mailto:babokin@gmail.com">babokin@gmail.com</a>> wrote:<br><br>> Nadav,<br>> <br>> You are absolutely right,
it's ISPC workload. I've checked SSE4 and it's also severely affected.<br>> <br>> We use intrinsics only for conversion <N x i32> <=> i32, i.e. movmsk.ps. For the rest we use general LLVM instructions. And I actually would really like to stick this way. We rely on LLVM's ability to produce efficient code from general LLVM IR. Relying on intrinsics too much would be a crunch and a path to nowhere for many reasons :)<br>> <br>> What is the reason for this transformation, if it doesn't lead to efficient code?<br>> <br>> Dmitry.<br>> <br>> <br>> <br>> On Mon, Oct 21, 2013 at 7:01 PM, Nadav Rotem <<a ymailto="mailto:nrotem@apple.com" href="mailto:nrotem@apple.com">nrotem@apple.com</a>> wrote:<br>> Hi Dmitry.<br>> <br>> This looks like an ISPC workload. ISPC works around a limitation in selection dag which does not know how to legalize mask types when both 128 and 256 bit registers are available. ISPC
works around this problem by expanding the mask to i32s and using intrinsics. Can you please verify that this regression only happens on AVX ? Can you change ISPC to use intrinsics ?<br>> <br>> Thanks<br>> Nadav<br>> <br>> Sent from my iPhone<br>> <br>> > On Oct 21, 2013, at 4:04, Dmitry Babokin <<a ymailto="mailto:babokin@gmail.com" href="mailto:babokin@gmail.com">babokin@gmail.com</a>> wrote:<br>> ><br>> > Nadav,<br>> ><br>> > Could you please have a look at bug #16941 and let us know what you think about it? It's performance regression after one of your commits.<br>> ><br>> > Thanks.<br>> ><br>> > Dmitry.<br>> <br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/4224f7d4/attachment-0001.html"
target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/4224f7d4/attachment-0001.html</a>><br><br>------------------------------<br><br>Message: 3<br>Date: Mon, 21 Oct 2013 11:23:01 -0700<br>From: Reid Kleckner <<a ymailto="mailto:rnk@google.com" href="mailto:rnk@google.com">rnk@google.com</a>><br>To: Yonggang Luo <<a ymailto="mailto:luoyonggang@gmail.com" href="mailto:luoyonggang@gmail.com">luoyonggang@gmail.com</a>><br>Cc: LLVM Dev <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] Feature request for include llvm-mc in<br> llvm.org/builds<br>Message-ID:<br> <CACs=tyJvw+<a ymailto="mailto:XgZ9S2n3NvSZBYMqqFaiUPfyQvuMZ9GMWczmCU-w@mail.gmail.com" href="mailto:XgZ9S2n3NvSZBYMqqFaiUPfyQvuMZ9GMWczmCU-w@mail.gmail.com">XgZ9S2n3NvSZBYMqqFaiUPfyQvuMZ9GMWczmCU-w@mail.gmail.com</a>><br>Content-Type:
text/plain; charset="gb2312"<br><br>I can confirm I get the same behavior, and that's a real bug. If you use<br>--target=i686-pc-win32, you get COFF, and that should be a good workaround<br>for now. There must be a conditional somewhere that isn't handling mingw<br>correctly.<br><br><br>On Sat, Oct 19, 2013 at 7:58 AM, ???(Yonggang Luo) <<a ymailto="mailto:luoyonggang@gmail.com" href="mailto:luoyonggang@gmail.com">luoyonggang@gmail.com</a>>wrote:<br><br>> 2013/10/19 Rafael Esp?ndola <<a ymailto="mailto:rafael.espindola@gmail.com" href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>>:<br>> > On 19 October 2013 06:01, ???(Yonggang Luo) <<a ymailto="mailto:luoyonggang@gmail.com" href="mailto:luoyonggang@gmail.com">luoyonggang@gmail.com</a>><br>> wrote:<br>> >> I found that access llvm-mc from clang driver is impossible, and I<br>> >> want to use llvm-mc to compile assembly
files, how to do that?<br>> ><br>> > Try "clang -integrated-as -c test.s"<br>><br>> Thank you very much, I use the following command compiled successfully:<br>> clang -integrated-as -c -v --target=i686-pc-mingw sqrt.s<br>><br>><br>> The output format is file format ELF32-i386, i wanna to know<br>> is there a way to output COFF format along with target=i686-pc-mingw.<br>> because I want to compile to following asm file for both linux/gcc and<br>> windows/visual C++.<br>><br>> .global sqrt<br>> .type sqrt,@function<br>> sqrt: fldl 4(%esp)<br>> fsqrt<br>> fstsw %ax<br>> sub $12,%esp<br>> fld %st(0)<br>> fstpt (%esp)<br>> mov (%esp),%ecx<br>> and $0x7ff,%ecx<br>> cmp $0x400,%ecx<br>> jnz 1f<br>> and $0x200,%eax<br>> sub $0x100,%eax<br>> sub %eax,(%esp)<br>> fstp %st(0)<br>> fldt (%esp)<br>> 1: add $12,%esp<br>> fstpl 4(%esp)<br>> fldl 4(%esp)<br>>
ret<br>><br>> ><br>> > Cheers,<br>> > Rafael<br>><br>><br>><br>> --<br>> ??<br>> ?<br>> ???<br>> Yours<br>> sincerely,<br>> Yonggang Luo<br>><br>> _______________________________________________<br>> LLVM Developers mailing list<br>> <a ymailto="mailto:LLVMdev@cs.uiuc.edu" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/c1bc27b9/attachment-0001.html"
target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/c1bc27b9/attachment-0001.html</a>><br><br>------------------------------<br><br>Message: 4<br>Date: Mon, 21 Oct 2013 11:43:57 -0700<br>From: Reid Kleckner <<a ymailto="mailto:rnk@google.com" href="mailto:rnk@google.com">rnk@google.com</a>><br>To: Yonggang Luo <<a ymailto="mailto:luoyonggang@gmail.com" href="mailto:luoyonggang@gmail.com">luoyonggang@gmail.com</a>><br>Cc: LLVM Dev <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] Feature request for include llvm-mc in<br> llvm.org/builds<br>Message-ID:<br> <CACs=tyKD=<a ymailto="mailto:LzoyHG90V8HU_W6L_Qs9w3ZMxUCUgjk_qGJ5RY-Ww@mail.gmail.com" href="mailto:LzoyHG90V8HU_W6L_Qs9w3ZMxUCUgjk_qGJ5RY-Ww@mail.gmail.com">LzoyHG90V8HU_W6L_Qs9w3ZMxUCUgjk_qGJ5RY-Ww@mail.gmail.com</a>><br>Content-Type:
text/plain; charset="gb2312"<br><br>Ah, so clang only understands the spelling mingw32, not mingw. That'll<br>give you COFF. :)<br><br><br>On Mon, Oct 21, 2013 at 11:23 AM, Reid Kleckner <<a ymailto="mailto:rnk@google.com" href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br><br>> I can confirm I get the same behavior, and that's a real bug. If you use<br>> --target=i686-pc-win32, you get COFF, and that should be a good workaround<br>> for now. There must be a conditional somewhere that isn't handling mingw<br>> correctly.<br>><br>><br>> On Sat, Oct 19, 2013 at 7:58 AM, ???(Yonggang Luo) <<a ymailto="mailto:luoyonggang@gmail.com" href="mailto:luoyonggang@gmail.com">luoyonggang@gmail.com</a>>wrote:<br>><br>>> 2013/10/19 Rafael Esp?ndola <<a ymailto="mailto:rafael.espindola@gmail.com" href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>>:<br>>> > On
19 October 2013 06:01, ???(Yonggang Luo) <<a ymailto="mailto:luoyonggang@gmail.com" href="mailto:luoyonggang@gmail.com">luoyonggang@gmail.com</a>><br>>> wrote:<br>>> >> I found that access llvm-mc from clang driver is impossible, and I<br>>> >> want to use llvm-mc to compile assembly files, how to do that?<br>>> ><br>>> > Try "clang -integrated-as -c test.s"<br>>><br>>> Thank you very much, I use the following command compiled successfully:<br>>> clang -integrated-as -c -v --target=i686-pc-mingw sqrt.s<br>>><br>>><br>>> The output format is file format ELF32-i386, i wanna to know<br>>> is there a way to output COFF format along with target=i686-pc-mingw.<br>>> because I want to compile to following asm file for both linux/gcc and<br>>> windows/visual C++.<br>>><br>>> .global sqrt<br>>> .type sqrt,@function<br>>> sqrt:
fldl 4(%esp)<br>>> fsqrt<br>>> fstsw %ax<br>>> sub $12,%esp<br>>> fld %st(0)<br>>> fstpt (%esp)<br>>> mov (%esp),%ecx<br>>> and $0x7ff,%ecx<br>>> cmp $0x400,%ecx<br>>> jnz 1f<br>>> and $0x200,%eax<br>>> sub $0x100,%eax<br>>> sub %eax,(%esp)<br>>> fstp %st(0)<br>>> fldt (%esp)<br>>> 1: add $12,%esp<br>>> fstpl 4(%esp)<br>>> fldl 4(%esp)<br>>> ret<br>>><br>>> ><br>>> > Cheers,<br>>> > Rafael<br>>><br>>><br>>><br>>> --<br>>> ??<br>>> ?<br>>> ???<br>>> Yours<br>>> sincerely,<br>>> Yonggang Luo<br>>><br>>> _______________________________________________<br>>> LLVM Developers mailing list<br>>> <a ymailto="mailto:LLVMdev@cs.uiuc.edu"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>>><br>><br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/0c1eb922/attachment-0001.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/0c1eb922/attachment-0001.html</a>><br><br>------------------------------<br><br>Message: 5<br>Date: Mon, 21 Oct 2013 23:09:59 +0400<br>From: Dmitry Babokin <<a ymailto="mailto:babokin@gmail.com" href="mailto:babokin@gmail.com">babokin@gmail.com</a>><br>To: Nadav Rotem <<a ymailto="mailto:nrotem@apple.com"
href="mailto:nrotem@apple.com">nrotem@apple.com</a>><br>Cc: Ilia Filippov <<a ymailto="mailto:ili.filippov@gmail.com" href="mailto:ili.filippov@gmail.com">ili.filippov@gmail.com</a>>, LLVM Developers Mailing<br> List <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] Bug #16941<br>Message-ID:<br> <CACRFwujWT6hGihJh9NSbAjBC87FTaHEd8mZ=<a ymailto="mailto:muryXJZtxPK3iw@mail.gmail.com" href="mailto:muryXJZtxPK3iw@mail.gmail.com">muryXJZtxPK3iw@mail.gmail.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>Nadav,<br><br>You are right, ISPC may issue intrinsics as a result of AST selection.<br>Though I believe that we should stick to LLVM IR whenever is possible.<br>Intrinsics may appear to be boundaries for optimizations (on both data and<br>control flow) and are generally not optimizable. LLVM
may improve over time<br>from performance stand point and we would benefit from it (or it may play<br>against us, like in this case). We can change out IR generation, but not in<br>favor of intrinsics (in long term, though we may use them as workaround, os<br>course).<br><br>I'm not sure that select is really a canonical form of this operation, as<br>it really assumes AND in this case. But this is a philosophical question,<br>so no point to argue :) In any case it should lead to more efficient code.<br>Which means that a) this transformation should not happen or b) code<br>generation for this instruction combination should be tuned. This should<br>benefit LLVM in general IMHO. It also may be the case that this just leads<br>to the bad code only in our specific environment, but at this point it<br>doesn't seems to be the case.<br><br>I'll try to come up with small SSE4 reproducer.<br><br>By the way, I'm curious, is the any reason why you focus on SSE4,
not AVX?<br>Seems that vectorizer should care the most about the latest silicon.<br><br>Dmitry.<br><br><br>On Mon, Oct 21, 2013 at 10:18 PM, Nadav Rotem <<a ymailto="mailto:nrotem@apple.com" href="mailto:nrotem@apple.com">nrotem@apple.com</a>> wrote:<br><br>> Hi Dmitry,<br>><br>> ISPC does some instruction selection as part of vectorization (on ASTs!)<br>> by placing intrinsics for specific operations. The SEXT to i32 pattern was<br>> implemented because LLVM did not support vector-selects when this code was<br>> written.<br>><br>> Can you submit a small SSE4 test case that demonstrates the problem?<br>> Select is the canonical form of this operations, and SEXT is usually more<br>> difficult to lower.<br>><br>> Thanks,<br>> Nadav<br>><br>> On Oct 21, 2013, at 11:12 AM, Dmitry Babokin <<a ymailto="mailto:babokin@gmail.com" href="mailto:babokin@gmail.com">babokin@gmail.com</a>>
wrote:<br>><br>> Nadav,<br>><br>> You are absolutely right, it's ISPC workload. I've checked SSE4 and it's<br>> also severely affected.<br>><br>> We use intrinsics only for conversion <N x i32> <=> i32, i.e. movmsk.ps.<br>> For the rest we use general LLVM instructions. And I actually would really<br>> like to stick this way. We rely on LLVM's ability to produce efficient code<br>> from general LLVM IR. Relying on intrinsics too much would be a crunch and<br>> a path to nowhere for many reasons :)<br>><br>> What is the reason for this transformation, if it doesn't lead to<br>> efficient code?<br>><br>> Dmitry.<br>><br>><br>><br>> On Mon, Oct 21, 2013 at 7:01 PM, Nadav Rotem <<a ymailto="mailto:nrotem@apple.com" href="mailto:nrotem@apple.com">nrotem@apple.com</a>> wrote:<br>><br>>> Hi Dmitry.<br>>><br>>> This looks like an ISPC workload. ISPC works around a
limitation in<br>>> selection dag which does not know how to legalize mask types when both 128<br>>> and 256 bit registers are available. ISPC works around this problem by<br>>> expanding the mask to i32s and using intrinsics. Can you please verify that<br>>> this regression only happens on AVX ? Can you change ISPC to use intrinsics<br>>> ?<br>>><br>>> Thanks<br>>> Nadav<br>>><br>>> Sent from my iPhone<br>>><br>>> > On Oct 21, 2013, at 4:04, Dmitry Babokin <<a ymailto="mailto:babokin@gmail.com" href="mailto:babokin@gmail.com">babokin@gmail.com</a>> wrote:<br>>> ><br>>> > Nadav,<br>>> ><br>>> > Could you please have a look at bug #16941 and let us know what you<br>>> think about it? It's performance regression after one of your commits.<br>>> ><br>>> > Thanks.<br>>> ><br>>> >
Dmitry.<br>>><br>><br>><br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/5209cc70/attachment-0001.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/5209cc70/attachment-0001.html</a>><br><br>------------------------------<br><br>Message: 6<br>Date: Mon, 21 Oct 2013 14:58:55 -0500<br>From: Arnold Schwaighofer <<a ymailto="mailto:aschwaighofer@apple.com" href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>><br>To: Renato Golin <<a ymailto="mailto:renato.golin@linaro.org" href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>><br>Cc: LLVM Dev <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] First attempt at recognizing pointer reduction<br>Message-ID: <<a
ymailto="mailto:C6D42D81-67E5-45D7-9430-14321A29634B@apple.com" href="mailto:C6D42D81-67E5-45D7-9430-14321A29634B@apple.com">C6D42D81-67E5-45D7-9430-14321A29634B@apple.com</a>><br>Content-Type: text/plain; charset=windows-1252<br><br><br>On Oct 21, 2013, at 1:00 PM, Renato Golin <<a ymailto="mailto:renato.golin@linaro.org" href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br><br>> Hi Arnold,<br>> <br>> To sum up my intentions, I want to understand how the reduction/induction variable detection works in LLVM, so that I can know better how to detect different patterns in memory, not just the stride vectorization. <br><br>To detect memory access patterns you will want to look at the SCEV of a pointer (or at a set of SCEVs/pointers). This way you get a canonical form.<br><br>For example these should be the SCEVs of ?int a[2*i] = ; a[2*i+1] =?:<br><br>{ptr, +, 8}_loop<br>{ptr+4, +, 8}_loop<br><br>Each access
on its own requires a gather/scather (2 loads/stores when vectorized (VF=2) + inserts/extracts). But when we look at both at once we see that we only need two load/store in total (plus some interleaving operations).<br><br>What other patterns (than strided accesses) do you want to vectorize?<br><br>> <br>> For instance, even if the relationship between each loop would be complicated, I know that in each loop, all three reads are sequential. So, at least, I could use a Load<3> rather than three loads.<br><br><br>Yes. Detecting this is what is described in the paper I referred in a post before (Auto-vectorization of interleaved data for SIMD). And what gcc is doing (AFAICT). You want to take a set of accesses in the loop and recognize that they are consecutive in memory (currently we look at every access on it is own, if an access is not sequential we assume we have to gather/scather). Once you know that you have consecutive accesses spread
across different instructions you can generate more efficient code instead of scather/gathers. You would want to do the evaluation of which accesses are consecutive in SCEV I think. <br><br>For your example, you want to recognize strided accesses (this is separate from the induction/reduction mechanism), first:<br><br>for (i = 0 .. n, +1)<br> a[2*i] = ?<br> a[2*1+1] = ?<br><br>You want this part first because without it the loop vectorizer is not going to vectorize because of the cost of gather/scather. But if it can recognize that in cases like this the ?gather/scather? is not as costly and we emit the right code we will start to vectorize such loops.<br><br>Once we can do that. We need to support strided pointer inductions to get your example.<br><br>for (i = 0..n, +1)<br> *a++=<br> *a++=<br><br><br>> I guess this is why Nadav was hinting for the SLP vectorizer, not the loop vec. Since the operation on all three loaded values are exactly the same
AND the writes are also sequential, I can reduce that to: load<3> -> op<3> -><br>> store<3>. That should work even on machines that don't have de-interleaved access (assuming they're pointers to simple types, etc).<br><br>Getting this example in the slp vectorizer is easier but we won?t get the most efficient code (i.e. the one that gcc emits) because we would have <3 x i8> stores/loads. With vectorization of interleaved data you can load/store more elements (from several iterations) with a single load.<br><br>> <br>> <br>> On 21 October 2013 17:29, Arnold Schwaighofer <<a ymailto="mailto:aschwaighofer@apple.com" href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>> wrote:<br>> can you post a hand-created vectorized IR of how a reduction would work on your example?<br>> <br>> I'm not there yet, just trying to understand the induction/reduction code first and what comes out of
it.<br>> <br>> <br>> I think the right approach to get examples like this is that we need to recognize strided pointer inductions (we only support strides by one currently).<br>> <br>> I see. I'll have a look at IK_PtrInduction and see what patterns I can spot.<br>> <br>> Do you envisage a new IK type for strided induction, or just work with the PtrInduction to extend the concept of a non-unit stride (ie. separate Step from ElementSize)?<br><br>Either representation should be fine. I think the bigger task is not recognizing the induction but recognizing consecutive strided memory accesses, though. First, I think we want to be able to do:<br><br>for (i = 0 ? n, +1)<br> a[3*i] =<br> a[3*i+1] =<br> a[3*i+2] =<br><br>And next,<br><br>for (i = 0 ? n, +1)<br> *a++ =<br> *a++ =<br> *a++ =<br> <br>Because to get the latter, you need the former.<br><br><br>Have you compared the performance of the
kernel (gcc vectorized) you showed vs a scalar version? I would be curious about the speed-up.<br><br><br>Thanks,<br>Arnold<br><br><br>------------------------------<br><br>Message: 7<br>Date: Tue, 22 Oct 2013 00:08:01 +0400<br>From: Simon Atanasyan <<a ymailto="mailto:simon@atanasyan.com" href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>><br>To: llvmdev <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: [LLVMdev] [lld] Handle _GLOBAL_OFFSET_TABLE symbol<br>Message-ID:<br> <CAGyS+DRSEmE1aqyCHn=<a ymailto="mailto:zpxFBR7Ynjj5MyPxMp01yJXXQBzgp8g@mail.gmail.com" href="mailto:zpxFBR7Ynjj5MyPxMp01yJXXQBzgp8g@mail.gmail.com">zpxFBR7Ynjj5MyPxMp01yJXXQBzgp8g@mail.gmail.com</a>><br>Content-Type: text/plain; charset=UTF-8<br><br>Hi,<br><br>What is a recommended way of handling (define, assign value)<br>_GLOBAL_OFFSET_TABLE symbol? It looks like Hexagon and
X86_64 targets<br>use different API to achieve the same result.<br><br>tia,<br><br>Simon<br><br><br>------------------------------<br><br>Message: 8<br>Date: Mon, 21 Oct 2013 15:16:58 -0500<br>From: Shankar Easwaran <<a ymailto="mailto:shankare@codeaurora.org" href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>><br>To: Simon Atanasyan <<a ymailto="mailto:simon@atanasyan.com" href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>>, llvmdev<br> <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] [lld] Handle _GLOBAL_OFFSET_TABLE symbol<br>Message-ID: <<a ymailto="mailto:52658BBA.4000203@codeaurora.org" href="mailto:52658BBA.4000203@codeaurora.org">52658BBA.4000203@codeaurora.org</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>Its a DefinedAtom whose value is set by the Target Handlers.<br><br>On
10/21/2013 3:08 PM, Simon Atanasyan wrote:<br>> Hi,<br>><br>> What is a recommended way of handling (define, assign value)<br>> _GLOBAL_OFFSET_TABLE symbol? It looks like Hexagon and X86_64 targets<br>> use different API to achieve the same result.<br>><br>> tia,<br>><br>> Simon<br>> _______________________________________________<br>> LLVM Developers mailing list<br>> <a ymailto="mailto:LLVMdev@cs.uiuc.edu" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>><br>><br><br><br>-- <br>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br><br><br><br>------------------------------<br><br>Message: 9<br>Date: Mon, 21 Oct
2013 21:40:38 +0100<br>From: Renato Golin <<a ymailto="mailto:renato.golin@linaro.org" href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>><br>To: Arnold Schwaighofer <<a ymailto="mailto:aschwaighofer@apple.com" href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>><br>Cc: LLVM Dev <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] First attempt at recognizing pointer reduction<br>Message-ID:<br> <<a ymailto="mailto:CAMSE1kc7H9Ev9LKYhEUbkj1NGuNDCq_1k90SvsaYXKx5e3SO4w@mail.gmail.com" href="mailto:CAMSE1kc7H9Ev9LKYhEUbkj1NGuNDCq_1k90SvsaYXKx5e3SO4w@mail.gmail.com">CAMSE1kc7H9Ev9LKYhEUbkj1NGuNDCq_1k90SvsaYXKx5e3SO4w@mail.gmail.com</a>><br>Content-Type: text/plain; charset="windows-1252"<br><br>On 21 October 2013 20:58, Arnold Schwaighofer <<a ymailto="mailto:aschwaighofer@apple.com"
href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>>wrote:<br><br>> For example these should be the SCEVs of ?int a[2*i] = ; a[2*i+1] =?:<br>><br>> {ptr, +, 8}_loop<br>> {ptr+4, +, 8}_loop<br>><br>> Each access on its own requires a gather/scather (2 loads/stores when<br>> vectorized (VF=2) + inserts/extracts). But when we look at both at once we<br>> see that we only need two load/store in total (plus some interleaving<br>> operations).<br>><br><br><br>Yes, I've been studying SCEV when trying to understand some other patterns<br>where the vectorizer was unable to detect the exit count (basically this<br>case, with a nested loop). It does make things easier to spot patterns in<br>the code.<br><br>The patch I attached here was not to help vectorize anything, but to let me<br>jump over the validation step, so that I could start working with the<br>patterns themselves during the actual vectorization.
The review request was<br>only to understand if the checks I was making made sense, but it turned out<br>a lot more valuable than that.<br><br><br>Getting this example in the slp vectorizer is easier but we won?t get the<br>> most efficient code (i.e. the one that gcc emits) because we would have <3<br>> x i8> stores/loads. With vectorization of interleaved data you can<br>> load/store more elements (from several iterations) with a single load.<br>><br><br>So, this was the other patterns I was looking for, as a stepping stone into<br>the full vectorizer. But I'm not sure this will help in any way the strided<br>access.<br><br><br><br>Either representation should be fine. I think the bigger task is not<br>> recognizing the induction but recognizing consecutive strided memory<br>> accesses, though. First, I think we want to be able to do:<br>><br>> for (i = 0 ? n, +1)<br>> a[3*i] =<br>> a[3*i+1]
=<br>> a[3*i+2] =<br>><br>> And next,<br>><br>> for (i = 0 ? n, +1)<br>> *a++ =<br>> *a++ =<br>> *a++ =<br>><br>> Because to get the latter, you need the former.<br>><br><br>Makes total sense. I'll change my approach.<br><br><br>Have you compared the performance of the kernel (gcc vectorized) you showed<br>> vs a scalar version? I would be curious about the speed-up.<br>><br><br>4x faster, on both Cortex A9 and A15. :)<br><br>Thanks for the tips, I hope I can find more time to work on it this week,<br>since Linaro Connect is in the coming week and the US dev meeting is on the<br>next.<br><br>cheers,<br>--renato<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/c0d72575/attachment-0001.html"
target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/c0d72575/attachment-0001.html</a>><br><br>------------------------------<br><br>Message: 10<br>Date: Tue, 22 Oct 2013 00:47:44 +0400<br>From: Simon Atanasyan <<a ymailto="mailto:simon@atanasyan.com" href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>><br>To: Shankar Easwaran <<a ymailto="mailto:shankare@codeaurora.org" href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>><br>Cc: llvmdev <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] [lld] Handle _GLOBAL_OFFSET_TABLE symbol<br>Message-ID:<br> <CAGyS+DSCbWZEfuWONXqnuLxvDEsLbdM=i=UL8FKM+<a ymailto="mailto:wdf9F-LHw@mail.gmail.com" href="mailto:wdf9F-LHw@mail.gmail.com">wdf9F-LHw@mail.gmail.com</a>><br>Content-Type: text/plain; charset=UTF-8<br><br>The Hexagon target adds new atom using
the addAbsoluteAtom() functions<br>and then assigns a virtual address in the finalizeSymbolValues()<br>routine. The X86_64 target uses addAtom() function to add an object of<br>the GLOBAL_OFFSET_TABLEAtom class to do the same thing. What is the<br>reason of this difference? Is the GLOBAL_OFFSET_TABLEAtom just a<br>useful wrapper which eliminates the necessity to assign an address to<br>the atom explicitly in the finalizeSymbolValues() routine?<br><br>On Tue, Oct 22, 2013 at 12:16 AM, Shankar Easwaran<br><<a ymailto="mailto:shankare@codeaurora.org" href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:<br>> Its a DefinedAtom whose value is set by the Target Handlers.<br>><br>> On 10/21/2013 3:08 PM, Simon Atanasyan wrote:<br>>> What is a recommended way of handling (define, assign value)<br>>> _GLOBAL_OFFSET_TABLE symbol? It looks like Hexagon and X86_64 targets<br>>> use different API to achieve the
same result.<br><br>-- <br>Simon<br><br><br>------------------------------<br><br>Message: 11<br>Date: Mon, 21 Oct 2013 15:51:53 -0500<br>From: Arnold Schwaighofer <<a ymailto="mailto:aschwaighofer@apple.com" href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>><br>To: Renato Golin <<a ymailto="mailto:renato.golin@linaro.org" href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>><br>Cc: LLVM Dev <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] First attempt at recognizing pointer reduction<br>Message-ID: <<a ymailto="mailto:F1F91875-68E1-437A-9629-ABFF3ABB9466@apple.com" href="mailto:F1F91875-68E1-437A-9629-ABFF3ABB9466@apple.com">F1F91875-68E1-437A-9629-ABFF3ABB9466@apple.com</a>><br>Content-Type: text/plain; charset=windows-1252<br><br>Whenever you find time to work on this will be of great help!<br><br>I wanted to work on this
at some point. But my near time tasks won?t allow. So I much appreciate any help!<br><br><br>Thanks,<br>Arnold<br><br>On Oct 21, 2013, at 3:40 PM, Renato Golin <<a ymailto="mailto:renato.golin@linaro.org" href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br><br>> On 21 October 2013 20:58, Arnold Schwaighofer <<a ymailto="mailto:aschwaighofer@apple.com" href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>> wrote:<br>> For example these should be the SCEVs of ?int a[2*i] = ; a[2*i+1] =?:<br>> <br>> {ptr, +, 8}_loop<br>> {ptr+4, +, 8}_loop<br>> <br>> Each access on its own requires a gather/scather (2 loads/stores when vectorized (VF=2) + inserts/extracts). But when we look at both at once we see that we only need two load/store in total (plus some interleaving operations).<br>> <br>> <br>> Yes, I've been studying SCEV when trying to understand some other patterns where
the vectorizer was unable to detect the exit count (basically this case, with a nested loop). It does make things easier to spot patterns in the code.<br>> <br>> The patch I attached here was not to help vectorize anything, but to let me jump over the validation step, so that I could start working with the patterns themselves during the actual vectorization. The review request was only to understand if the checks I was making made sense, but it turned out a lot more valuable than that.<br>> <br>> <br>> Getting this example in the slp vectorizer is easier but we won?t get the most efficient code (i.e. the one that gcc emits) because we would have <3 x i8> stores/loads. With vectorization of interleaved data you can load/store more elements (from several iterations) with a single load.<br>> <br>> So, this was the other patterns I was looking for, as a stepping stone into the full vectorizer. But I'm not sure this will help in
any way the strided access.<br>> <br>> <br>> <br>> Either representation should be fine. I think the bigger task is not recognizing the induction but recognizing consecutive strided memory accesses, though. First, I think we want to be able to do:<br>> <br>> for (i = 0 ? n, +1)<br>> a[3*i] =<br>> a[3*i+1] =<br>> a[3*i+2] =<br>> <br>> And next,<br>> <br>> for (i = 0 ? n, +1)<br>> *a++ =<br>> *a++ =<br>> *a++ =<br>> <br>> Because to get the latter, you need the former.<br>> <br>> Makes total sense. I'll change my approach.<br>> <br>> <br>> Have you compared the performance of the kernel (gcc vectorized) you showed vs a scalar version? I would be curious about the speed-up.<br>> <br>> 4x faster, on both Cortex A9 and A15. :)<br><br>Nice.<br><br>> <br>> Thanks for the tips, I hope I can find more time to work on it this week, since
Linaro Connect is in the coming week and the US dev meeting is on the next.<br>> <br>> cheers,<br>> --renato<br><br><br><br><br>------------------------------<br><br>Message: 12<br>Date: Mon, 21 Oct 2013 15:58:29 -0500<br>From: Shankar Easwaran <<a ymailto="mailto:shankare@codeaurora.org" href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>><br>To: Simon Atanasyan <<a ymailto="mailto:simon@atanasyan.com" href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>><br>Cc: llvmdev <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] [lld] Handle _GLOBAL_OFFSET_TABLE symbol<br>Message-ID: <<a ymailto="mailto:52659575.7090002@codeaurora.org" href="mailto:52659575.7090002@codeaurora.org">52659575.7090002@codeaurora.org</a>><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>On 10/21/2013 3:47 PM, Simon Atanasyan wrote:<br>>
The Hexagon target adds new atom using the addAbsoluteAtom() functions<br>> and then assigns a virtual address in the finalizeSymbolValues()<br>> routine. The X86_64 target uses addAtom() function to add an object of<br>> the GLOBAL_OFFSET_TABLEAtom class to do the same thing. What is the<br>> reason of this difference?<br>This should be fixed and both should use the addAbsoluteAtom function.<br><br>> Is the GLOBAL_OFFSET_TABLEAtom just a<br>> useful wrapper which eliminates the necessity to assign an address to<br>> the atom explicitly in the finalizeSymbolValues() routine?<br>Its being used as a wrapper currently, as this is an AbsoluteAtom and <br>not a DefinedAtom. This should also be fixed.<br><br>The problem is this is being treated as a DefinedAtom, which should be <br>an Absolute atom in my opinion.<br><br>Shankar Easwaran<br><br>-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, <br>hosted by the Linux
Foundation<br><br><br>------------------------------<br><br>Message: 13<br>Date: Mon, 21 Oct 2013 21:09:34 +0000<br>From: "Robinson, Paul" <<a ymailto="mailto:Paul_Robinson@playstation.sony.com" href="mailto:Paul_Robinson@playstation.sony.com">Paul_Robinson@playstation.sony.com</a>><br>To: "<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>" <<a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>>, "<a ymailto="mailto:cfe-dev@cs.uiuc.edu" href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>"<br> <<a ymailto="mailto:cfe-dev@cs.uiuc.edu" href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>><br>Subject: Re: [LLVMdev] llvm.org bug trend<br>Message-ID:<br> <<a ymailto="mailto:E3B07FDB86BFF041819DC057DEED8FEA5596B747@USCULXMSG02.am.sony.com"
href="mailto:E3B07FDB86BFF041819DC057DEED8FEA5596B747@USCULXMSG02.am.sony.com">E3B07FDB86BFF041819DC057DEED8FEA5596B747@USCULXMSG02.am.sony.com</a>><br>Content-Type: text/plain; charset="us-ascii"<br><br>This week, for the very first time since I started sampling (14 months ago),<br>the weekly open-bug count went DOWN.<br><br>Traffic on llvm-bugs indicates that Bill Wendling is doing a lot of this. Huzzah!<br>--paulr<br><br>From: <a ymailto="mailto:cfe-dev-bounces@cs.uiuc.edu" href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a> [mailto:<a ymailto="mailto:cfe-dev-bounces@cs.uiuc.edu" href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a>] On Behalf Of Robinson, Paul<br>Sent: Tuesday, July 30, 2013 11:32 AM<br>To: <a ymailto="mailto:llvmdev@cs.uiuc.edu" href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>; <a ymailto="mailto:cfe-dev@cs.uiuc.edu"
href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>Subject: [cfe-dev] llvm.org bug trend<br><br>Over most of the past year, I have been keeping an eye on the overall LLVM.org open-bug count.<br>Sampling the count (almost) every Monday morning, it is a consistently non-decreasing number.<br>I thought I'd post something about it to the Dev lists, as the count broke 4000 this past week.<br>For your entertainment here's a chart that Excel produced from the data. (To make it more<br>dramatic, I carefully did not use a proper zero point on the X-axis.)<br><br>I do not have per-category breakdowns, sorry, just the raw total.<br><br>Makes me think more seriously about cruising the bug list for something that looks like<br>I could actually fix it...<br>--paulr<br><br>[cid:<a ymailto="mailto:image001.png@01CE8C56.9A40D7E0" href="mailto:image001.png@01CE8C56.9A40D7E0">image001.png@01CE8C56.9A40D7E0</a>]<br><br><br><br>-------------- next part
--------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/e18e8251/attachment.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/e18e8251/attachment.html</a>><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: image001.png<br>Type: image/png<br>Size: 11909 bytes<br>Desc: image001.png<br>URL: <<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/e18e8251/attachment.png" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131021/e18e8251/attachment.png</a>><br><br>------------------------------<br><br>_______________________________________________<br>LLVMdev mailing list<br><a ymailto="mailto:LLVMdev@cs.uiuc.edu" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br><br><br>End of LLVMdev Digest, Vol 112, Issue 56<br>****************************************<br><br><br></div> </div> </div> </div> </div></body></html>