[LLVMdev] LLVMdev Digest, Vol 112, Issue 59
lipengcheng
pli at cs.rochester.edu
Tue Oct 22 11:22:56 PDT 2013
On Oct 22, 2013, at 1:29 PM, llvmdev-request at cs.uiuc.edu wrote:
> Send LLVMdev mailing list submissions to
> llvmdev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> or, via email, send a message with subject or body 'help' to
> llvmdev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
> llvmdev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of LLVMdev digest..."
>
>
> Today's Topics:
>
> 1. Fwd: Re: [lldb-dev] Has Fast register allocation been
> finished in 3.3 version? (??? (Yonggang Luo))
> 2. Re: Contribute a new precise pointer analysis to LLVM (lian li)
> 3. Re: Feature request for include llvm-mc in llvm.org/builds
> (??? (Yonggang Luo))
> 4. How to use clang -intergrated-as to compile cross-(os/target)
> assembly file. (??? (Yonggang Luo))
> 5. Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
> (Yaron Keren)
> 6. Removing function params. (James Courtier-Dutton)
> 7. Re: Removing function params. (John Criswell)
> 8. Re: Size limitations in MCJIT / ELF Dynamic Linker/ ELF
> codegen? (Kaylor, Andrew)
> 9. Re: [RFC] Stackmap and Patchpoint Intrinsic Proposal (Philip R)
> 10. Re: Contribute a new precise pointer analysis to LLVM (Hal Finkel)
> 11. Re: Contribute a new precise pointer analysis to LLVM
> (Chandler Carruth)
> 12. Re: Size limitations in MCJIT / ELF Dynamic Linker/ ELF
> codegen? (Yaron Keren)
> 13. Re: Contribute a new precise pointer analysis to LLVM (Hal Finkel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 Oct 2013 20:03:40 +0800
> From: ???(Yonggang Luo) <luoyonggang at gmail.com>
> To: LLVM Dev <llvmdev at cs.uiuc.edu>
> Subject: [LLVMdev] Fwd: Re: [lldb-dev] Has Fast register allocation
> been finished in 3.3 version?
> Message-ID:
> <CAE2XoE9z91QLiLdG5pr1sNW4PeSzN2_yyWK4KxTtBsGoDt85zA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Forward to llvmdev
> ---------- ????? ----------
> ????"Chris Lattner" <clattner at apple.com>
> ???2013?10?22? ??7:33
> ???Re: [lldb-dev] Has Fast register allocation been finished in 3.3 version?
> ???? <wansheg at gmail.com>
> ??? <lldb-dev at cs.uiuc.edu>
>
>
> On Oct 21, 2013, at 7:43 PM, wansheg at gmail.com wrote:
>
>
> When I use llc command with --regalloc=fast , get error
>
> In addition, is lli use fast register allocation?
>
>
> You should probably ask about this on the llvmdev mailing list, you'll
> reach the right audience there.
>
> -Chris
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131022/58d8b6ee/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 Oct 2013 23:35:08 +1000
> From: lian li <lianli at gmail.com>
> To: Evan Cheng <evan.cheng at apple.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Contribute a new precise pointer analysis to
> LLVM
> Message-ID:
> <CAAwsJt_u4t9XgwRK7Bm-iJ-PNtG3FX4y6iqfm8W4XXyYM95UpQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Evan,
>
> We did an experiment using the LLVM test suite: we compare the
> overhead of using our analysis to the LLVM default, both with -O2
> option.
>
> The overall overhead of compiling the whole test suite using our
> analysis is 36.5%.
> The biggest overhead is observed in
> "SingleSource/Benchmarks/Misc/flops-5", where we are 5 times slower:
> 0.07s (with our analysis) compared to 0.0133s(default).
> This may not be accurate as the compilation time in both cases are quite small.
>
> Remind that the compilation time is reported by running our analysis
> over individual files, the compilation time overhead will be larger if
> we link all individual compilation units together and run the
> analysis over the whole application.
>
> Regards,
> Lian
>
> On Sat, Oct 19, 2013 at 7:56 AM, Evan Cheng <evan.cheng at apple.com> wrote:
>>
>> On Oct 17, 2013, at 10:51 PM, lian li <lianli at gmail.com> wrote:
>>
>>> Thanks, Chris.
>>>
>>> We are interested in contributing it to LLVM itself. Our manager
>>> agrees to commit resources for maintenance needs if it is accepted by
>>> the community.
>>
>> This is great. Please make sure Oracle legal sign off on explicitly granting LLVM the use of the patents associated with the work.
>>
>> On the compile time front, can you do a comparison with the LLVM default and your new AA? You can just build the LLVM test suite.
>>
>> Thanks,
>>
>> Evan
>>
>>>
>>> Regards,
>>> Lian
>>>
>>> On Fri, Oct 18, 2013 at 3:43 PM, Chris Lattner <clattner at apple.com> wrote:
>>>>
>>>> On Oct 17, 2013, at 5:20 PM, lian li <lianli at gmail.com> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> This is Lian Li from Oracle Labs in Brisbane Australia.
>>>>
>>>> We have developed a precise and highly efficient pointer analysis
>>>> framework on top of LLVM, The approach is flow, context, and field
>>>> sensitive, details are described in the two papers below:
>>>>
>>>> "Boosting the performance of flow-sensitive points-to analysis using
>>>> value flow" (in ESEC-FSE 2011), and
>>>> "Precise and scalable context-sensitive pointer analysis via value
>>>> flow graph" (in ISMM 2013).
>>>>
>>>> The analysis was initially developed for the purpose of bug checking,
>>>> and is now extended to support compiler optimizations. We have tested
>>>> it with existing compiler optimizations in LLVM, and have seen
>>>> promising results.
>>>>
>>>> We are now considering to make this analysis available to the LLVM
>>>> community, and contribute resources for future maintenance needs,
>>>> provided that there is enough interest. We think that a new precise
>>>> pointer analysis in LLVM can enable more new optimization and analysis
>>>> techniques to be developed in LLVM.
>>>>
>>>> Any people interested in seeing a new precise pointer analysis in LLVM?
>>>>
>>>>
>>>> This sounds very interesting. Even if it isn't fast enough to be used with
>>>> (for example) clang -O2 or -O3, having such a precise analysis would be a
>>>> great baseline for doing other alias analysis work.
>>>>
>>>> Are you interested in contributing this to LLVM itself, or just asking if
>>>> people would be interested to see the code in some other form?
>>>>
>>>> -Chris
>>>
>>>
>>>
>>> --
>>> // Copyright @ 2011 Authorized by ** LIAN LI **
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> Interesting. And I am interested in that. If you can compare it with others technology,
would be greater.
>
> --
> // Copyright @ 2011 Authorized by ** LIAN LI **
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 22 Oct 2013 21:45:05 +0800
> From: ???(Yonggang Luo) <luoyonggang at gmail.com>
> To: Reid Kleckner <rnk at google.com>
> Cc: LLVM Dev <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Feature request for include llvm-mc in
> llvm.org/builds
> Message-ID:
> <CAE2XoE8KT7AdtT1bPXU1j+h8nXTY7XrqMUDXz54Fp1Xfr-14iA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2013/10/22 Reid Kleckner <rnk at google.com>:
>> Ah, so clang only understands the spelling mingw32, not mingw. That'll give
>> you COFF. :)
>
> Thanks a lot, I found how it's works, use both
> clang -integrated-as -c -v --target=i686-pc-win32 sqrt.s
> clang -integrated-as -c -v --target=i686-pc-mingw32 sqrt.s
> works. Just because my sqrt.s source code file is invalid for win32.
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 22 Oct 2013 22:08:47 +0800
> From: ???(Yonggang Luo) <luoyonggang at gmail.com>
> To: LLVM Dev <llvmdev at cs.uiuc.edu>
> Subject: [LLVMdev] How to use clang -intergrated-as to compile
> cross-(os/target) assembly file.
> Message-ID:
> <CAE2XoE-2780jMBL5kLtO8rXpfW_mrTkgjpix7WR+WH0-NGxivw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> For example, I execute the following command sequences:
>
> H:\CI\bld\compilers\musl\src\math\i386>type sqrt.s
> #.globl _sqrt
> .global sqrt
> #.type sqrt, at function
> #_sqrt:
> sqrt: fldl 4(%esp)
> fsqrt
> fstsw %ax
> sub $12,%esp
> fld %st(0)
> fstpt (%esp)
> mov (%esp),%ecx
> and $0x7ff,%ecx
> cmp $0x400,%ecx
> jnz 1f
> and $0x200,%eax
> sub $0x100,%eax
> sub %eax,(%esp)
> fstp %st(0)
> fldt (%esp)
> 1: add $12,%esp
> fstpl 4(%esp)
> fldl 4(%esp)
> ret
>
> H:\CI\bld\compilers\musl\src\math\i386>type sqrt.c
> float __cdecl sqrt(float z)
> {
> return 0.0;
> }
> H:\CI\bld\compilers\musl\src\math\i386>clang -integrated-as -c -v
> --target=i686
> -pc-win32 sqrt.s
> clang version 3.4 (trunk)
> Target: i686-pc-win32
> Thread model: posix
> "C:\Program Files (x86)\LLVM 3.4.svn\bin\clang.exe" -cc1as -triple
> i686-pc-win3
> 2 -filetype obj -main-file-name sqrt.s -target-cpu pentium4
> -fdebug-compilation-
> dir "H:\\CI\\bld\\compilers\\musl\\src\\math\\i386" -dwarf-debug-producer
> clang
> version 3.4 (trunk) -o sqrt.o sqrt.s
>
> H:\CI\bld\compilers\musl\src\math\i386>llvm-objdump -s -r -t sqrt.o
>
> sqrt.o: file format COFF-i386
>
> Contents of section .text:
> 0000 dd442404 d9fa9bdf e083ec0c d9c0db3c .D$............<
> 0010 248b0c24 81e1ff07 000081f9 00040000 $..$............
> 0020 75122500 0200002d 00010000 290424dd u.%....-....).$.
> 0030 d8db2c24 83c40cdd 5c2404dd 442404c3 ..,$....\$..D$..
> SYMBOL TABLE:
> [ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text
> AUX scnlen 0x40 nreloc 0 nlnno 0 checksum 0x0 assoc 1 comdat 0
> [ 2](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 sqrt
>
> H:\CI\bld\compilers\musl\src\math\i386>clang --target=i686-pc-win32 -c
> sqrt.c
> sqrt.c:1:15: warning: incompatible redeclaration of library function 'sqrt'
> [-Wincompatible-library-redeclaration]
> float __cdecl sqrt(float z)
> ^
> sqrt.c:1:15: note: 'sqrt' is a builtin with type 'double (double)'
> 1 warning generated.
>
> H:\CI\bld\compilers\musl\src\math\i386>llvm-objdump -s -r -t sqrt.o
>
> sqrt.o: file format COFF-i386
>
> Contents of section .text:
> 0000 5589e583 ec08f30f 1045080f 57c9f30f U........E..W...
> 0010 1145fcd9 eef30f11 4df883c4 085dc3 .E......M....].
> SYMBOL TABLE:
> [ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text
> AUX scnlen 0x1f nreloc 0 nlnno 0 checksum 0x0 assoc 1 comdat 0
> [ 2](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000001 @feat.00
> [ 3](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 _sqrt
>
> H:\CI\bld\compilers\musl\src\math\i386>
> H:\CI\bld\compilers\musl\src\math\i386>clang -integrated-as -c -v
> --target=amd6
> 4-pc-win32 sqrt.s
> clang version 3.4 (trunk)
> Target: amd64-pc-win32
> Thread model: posix
> "C:\Program Files (x86)\LLVM 3.4.svn\bin\clang.exe" -cc1as -triple
> amd64-pc-win
> 32 -filetype obj -main-file-name sqrt.s -target-cpu x86-64
> -fdebug-compilation-d
> ir "H:\\CI\\bld\\compilers\\musl\\src\\math\\i386" -dwarf-debug-producer
> clang v
> ersion 3.4 (trunk) -o sqrt.o sqrt.s
>
> H:\CI\bld\compilers\musl\src\math\i386>llvm-objdump -s -r -t sqrt.o
>
> sqrt.o: file format COFF-x86-64
>
> Contents of section .text:
> 0000 67dd4424 04d9fa9b dfe083ec 0cd9c067 g.D$...........g
> 0010 db3c2467 8b0c2481 e1ff0700 0081f900 .<$g..$.........
> 0020 04000075 14250002 00002d00 01000067 ...u.%....-....g
> 0030 290424dd d867db2c 2483c40c 67dd5c24 ).$..g.,$...g.\$
> 0040 0467dd44 2404c3 .g.D$..
> SYMBOL TABLE:
> [ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text
> AUX scnlen 0x47 nreloc 0 nlnno 0 checksum 0x0 assoc 1 comdat 0
> [ 2](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 sqrt
>
> H:\CI\bld\compilers\musl\src\math\i386>clang --target=amd64-pc-win32 -c
> sqrt.c
> sqrt.c:1:15: warning: incompatible redeclaration of library function 'sqrt'
> [-Wincompatible-library-redeclaration]
> float __cdecl sqrt(float z)
> ^
> sqrt.c:1:15: note: 'sqrt' is a builtin with type 'double (double)'
> 1 warning generated.
>
> H:\CI\bld\compilers\musl\src\math\i386>llvm-objdump -s -r -t sqrt.o
>
> sqrt.o: file format COFF-x86-64
>
> Contents of section .text:
> 0000 554889e5 50f30f11 45fc0f57 c04883c4 UH..P...E..W.H..
> 0010 085dc3 .].
> SYMBOL TABLE:
> [ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text
> AUX scnlen 0x13 nreloc 0 nlnno 0 checksum 0x0 assoc 1 comdat 0
> [ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 sqrt
>
> H:\CI\bld\compilers\musl\src\math\i386>
>
> *
> *
> *My problem is:*
>
> Because C __cdecl calling convention vary on x86/amd64 architecture under
> win32.
> for example, the sqrt function in is expressed as
> float __cdecl sqrt(float)
>
> but in the compiled object file, the final COFF symbol table:
> on x86/win32(i686-pc-win32), it's named with "*_sqrt*"
> on amd64/win32(amd64-pc-win32), it's named with "*sqrt*"
>
>
>
> on linux(*-pc-linux), in ELF symbol table, it's named with "*sqrt*",
>
>
> So I want to control the function name in assembly file, by the means of
> Assembly macros,
> but I don't know LLVM-MC support which kinds of macros to control the
> assembly directives so that I can unified the assembly function name can
> match the c function name in object symbol table under different
> CPU(x86/x64) and different OS(Win32/Linux/MacOS).
> The simplest way is to duplicate the function name is to duplicate the
> function name in two form:
> .globl _sqrt
> .global sqrt
> #.type sqrt, at function
> _sqrt:
> sqrt: fldl 4(%esp)
> But that will leading redundant object symbol name.
> besides, the* .type *didn't support under COFF symbol table, so how did I
> use assembly macro to comment it out when we are targeting COFF object but
> reserved when we are targeting ELF.
> didn't know if Mach-O support for this directive.
>
> --
> ??
> ?
> ???
> Yours
> sincerely,
> Yonggang Luo
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131022/8af83fc7/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 22 Oct 2013 18:12:07 +0300
> From: Yaron Keren <yaron.keren at gmail.com>
> To: "<llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu>, "Kaylor, Andrew"
> <andrew.kaylor at intel.com>
> Subject: [LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF
> codegen?
> Message-ID:
> <CANa4zJr7up3H353-_dZwkj6RpDaU0S=Q=uSCFPVt61uMDCaFOQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I'm running in MCJIT a module generated from one C++ function. Every line
> of the source function uses C++ classes and may throw an exception. As long
> as there are less than (about) 1000 lines, everything works. With more
> lines the compiled code crashes when running it, with no sensible stack
> trace.
>
> Is there any kind of hard-coded size limitation in MCJIT / ELF Dynamic
> Linker / ELF codegen / number of EH states in a function ?
>
> I did browse the code but could not find anything obvious.
>
> Yaron
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131022/0fdbd30f/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 22 Oct 2013 16:17:36 +0100
> From: James Courtier-Dutton <james.dutton at gmail.com>
> To: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
> Subject: [LLVMdev] Removing function params.
> Message-ID:
> <CAAMvbhE771NgnJJB=2eqA43HQYjtSQ+gq2+9DFSHcz4tYarH1w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> I am writing my own passes in LLVM.
> I start with a function with various uses of a LLVM IR function
> parameter: e.g. paramB.
>
> After running one of my passes, all the uses of the paramB vanish.
> How do I do the last step, and remove the paramB from the function
> parameters in the LLVM IR?
>
> I want to go from:
> function test( int paramA, int paramB)
> { ... }
>
> to:
> function test( int paramA)
> { ... }
>
> Is there an LLVM IR API method that does this, or do I have to create
> a whole new function and add all the basic blocks and instructions
> from the old one to it?
>
> Also, how do I do the opposite:
> I want to go from:
> function test( int paramA)
> { ... }
>
> to:
> function test( int paramA, int paramB)
> { ... }
>
>
> Kind Regards
>
> James.
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 22 Oct 2013 10:27:57 -0500
> From: John Criswell <criswell at illinois.edu>
> To: James Courtier-Dutton <james.dutton at gmail.com>,
> "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Removing function params.
> Message-ID: <5266997D.8060800 at illinois.edu>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> On 10/22/13 10:17 AM, James Courtier-Dutton wrote:
>> Hi,
>>
>> I am writing my own passes in LLVM.
>> I start with a function with various uses of a LLVM IR function
>> parameter: e.g. paramB.
>>
>> After running one of my passes, all the uses of the paramB vanish.
>> How do I do the last step, and remove the paramB from the function
>> parameters in the LLVM IR?
>
> In order to add or remove parameters from a function, you will need to
> create a new function and clone the contents of the old function into
> the new function. You will then need to replace uses of the old
> function with the new function.
>
> There's a utility function called (I think) cloneFunctionInto which
> makes this whole process much simpler. Look for a source file with the
> word "Clone" in it in llvm/lib/Transforms; the function will be located
> there.
>
> As an FYI, if you want to remove an argument because it is unused, LLVM
> already has a transform pass that does that. I think it's
> DeadArgumentElimination.
>
> -- John T.
>
>>
>> I want to go from:
>> function test( int paramA, int paramB)
>> { ... }
>>
>> to:
>> function test( int paramA)
>> { ... }
>>
>> Is there an LLVM IR API method that does this, or do I have to create
>> a whole new function and add all the basic blocks and instructions
>> from the old one to it?
>>
>> Also, how do I do the opposite:
>> I want to go from:
>> function test( int paramA)
>> { ... }
>>
>> to:
>> function test( int paramA, int paramB)
>> { ... }
>>
>>
>> Kind Regards
>>
>> James.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 22 Oct 2013 16:44:29 +0000
> From: "Kaylor, Andrew" <andrew.kaylor at intel.com>
> To: Yaron Keren <yaron.keren at gmail.com>, "<llvmdev at cs.uiuc.edu>"
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/
> ELF codegen?
> Message-ID:
> <0983E6C011D2DC4188F8761B533492DE56467348 at ORSMSX104.amr.corp.intel.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> I'm not aware of such a limitation.
>
> What architecture, code model and relocation model are you using? Are you using the SectionMemoryManager?
>
> -Andy
>
> From: Yaron Keren [mailto:yaron.keren at gmail.com]
> Sent: Tuesday, October 22, 2013 8:12 AM
> To: <llvmdev at cs.uiuc.edu>; Kaylor, Andrew
> Subject: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
>
> I'm running in MCJIT a module generated from one C++ function. Every line of the source function uses C++ classes and may throw an exception. As long as there are less than (about) 1000 lines, everything works. With more lines the compiled code crashes when running it, with no sensible stack trace.
>
> Is there any kind of hard-coded size limitation in MCJIT / ELF Dynamic Linker / ELF codegen / number of EH states in a function ?
>
> I did browse the code but could not find anything obvious.
>
> Yaron
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131022/6e6395c9/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 22 Oct 2013 09:53:06 -0700
> From: Philip R <listmail at philipreames.com>
> To: Andrew Trick <atrick at apple.com>
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic
> Proposal
> Message-ID: <5266AD72.30502 at philipreames.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/17/13 10:39 PM, Andrew Trick wrote:
>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The
>> first client of these features is the JavaScript compiler within the
>> open source WebKit project.
>>
> I have a couple of comments on your proposal. None of these are major
> enough to prevent submission.
>
> - As others have said, I'd prefer an experimental namespace rather than
> a webkit namespace. (minor)
> - Unless I am misreading your proposal, your proposed StackMap intrinsic
> duplicates existing functionality already in llvm. In particular, much
> of the StackMap construction seems similar to the Safepoint mechanism
> used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and
> CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if
> you can share implementations?
> - To my knowledge, there is nothing that prevents an LLVM optimization
> pass from manufacturing new pointers which point inside an existing data
> structure. (e.g. an interior pointer to an array when blocking a loop)
> Does your StackMap mechanism need to be able to inspect/modify these
> manufactured temporaries? If so, I don't see how you could generate an
> intrinsic which would include this manufactured pointer in the live
> variable list. Is there something I'm missing here?
> - Your patchpoint mechanism appears to be one very specialized use of a
> patchable location. Would you mind renaming it to something like
> patchablecall to reflect this specialization?
>
> Yours,
> Philip
>
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 22 Oct 2013 11:55:57 -0500 (CDT)
> From: Hal Finkel <hfinkel at anl.gov>
> To: lian li <lianli at gmail.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Contribute a new precise pointer analysis to
> LLVM
> Message-ID:
> <969079291.5231342.1382460957618.JavaMail.root at alcf.anl.gov>
> Content-Type: text/plain; charset=utf-8
>
> ----- Original Message -----
>> Hi Evan,
>>
>> We did an experiment using the LLVM test suite: we compare the
>> overhead of using our analysis to the LLVM default, both with -O2
>> option.
>
> It might also be interesting to try with -O3; I don't know if we have any significant vectorizable loops in the test suite with a large number of arrays, but if we do, this kind of analysis should help.
>
>>
>> The overall overhead of compiling the whole test suite using our
>> analysis is 36.5%.
>
> Maybe a good candidate for -fexpensive-optimizations? (or -O4?)
>
>> The biggest overhead is observed in
>> "SingleSource/Benchmarks/Misc/flops-5", where we are 5 times slower:
>> 0.07s (with our analysis) compared to 0.0133s(default).
>> This may not be accurate as the compilation time in both cases are
>> quite small.
>
> In my experience, compile-time measurements from a normal test-suite configuration less than 0.1s are too noisy to use.
>
>>
>> Remind that the compilation time is reported by running our analysis
>> over individual files, the compilation time overhead will be larger
>> if
>> we link all individual compilation units together and run the
>> analysis over the whole application.
>
> Yes, LTO tests would be interesting too.
>
> Thanks again,
> Hal
>
>>
>> Regards,
>> Lian
>>
>> On Sat, Oct 19, 2013 at 7:56 AM, Evan Cheng <evan.cheng at apple.com>
>> wrote:
>>>
>>> On Oct 17, 2013, at 10:51 PM, lian li <lianli at gmail.com> wrote:
>>>
>>>> Thanks, Chris.
>>>>
>>>> We are interested in contributing it to LLVM itself. Our manager
>>>> agrees to commit resources for maintenance needs if it is accepted
>>>> by
>>>> the community.
>>>
>>> This is great. Please make sure Oracle legal sign off on explicitly
>>> granting LLVM the use of the patents associated with the work.
>>>
>>> On the compile time front, can you do a comparison with the LLVM
>>> default and your new AA? You can just build the LLVM test suite.
>>>
>>> Thanks,
>>>
>>> Evan
>>>
>>>>
>>>> Regards,
>>>> Lian
>>>>
>>>> On Fri, Oct 18, 2013 at 3:43 PM, Chris Lattner
>>>> <clattner at apple.com> wrote:
>>>>>
>>>>> On Oct 17, 2013, at 5:20 PM, lian li <lianli at gmail.com> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> This is Lian Li from Oracle Labs in Brisbane Australia.
>>>>>
>>>>> We have developed a precise and highly efficient pointer analysis
>>>>> framework on top of LLVM, The approach is flow, context, and
>>>>> field
>>>>> sensitive, details are described in the two papers below:
>>>>>
>>>>> "Boosting the performance of flow-sensitive points-to analysis
>>>>> using
>>>>> value flow" (in ESEC-FSE 2011), and
>>>>> "Precise and scalable context-sensitive pointer analysis via
>>>>> value
>>>>> flow graph" (in ISMM 2013).
>>>>>
>>>>> The analysis was initially developed for the purpose of bug
>>>>> checking,
>>>>> and is now extended to support compiler optimizations. We have
>>>>> tested
>>>>> it with existing compiler optimizations in LLVM, and have seen
>>>>> promising results.
>>>>>
>>>>> We are now considering to make this analysis available to the
>>>>> LLVM
>>>>> community, and contribute resources for future maintenance needs,
>>>>> provided that there is enough interest. We think that a new
>>>>> precise
>>>>> pointer analysis in LLVM can enable more new optimization and
>>>>> analysis
>>>>> techniques to be developed in LLVM.
>>>>>
>>>>> Any people interested in seeing a new precise pointer analysis in
>>>>> LLVM?
>>>>>
>>>>>
>>>>> This sounds very interesting. Even if it isn't fast enough to be
>>>>> used with
>>>>> (for example) clang -O2 or -O3, having such a precise analysis
>>>>> would be a
>>>>> great baseline for doing other alias analysis work.
>>>>>
>>>>> Are you interested in contributing this to LLVM itself, or just
>>>>> asking if
>>>>> people would be interested to see the code in some other form?
>>>>>
>>>>> -Chris
>>>>
>>>>
>>>>
>>>> --
>>>> // Copyright @ 2011 Authorized by ** LIAN LI **
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>>
>>
>> --
>> // Copyright @ 2011 Authorized by ** LIAN LI **
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 22 Oct 2013 10:07:57 -0700
> From: Chandler Carruth <chandlerc at google.com>
> To: Hal Finkel <hfinkel at anl.gov>
> Cc: lian li <lianli at gmail.com>, LLVM Developers Mailing List
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Contribute a new precise pointer analysis to
> LLVM
> Message-ID:
> <CAGCO0KhJJYnWg2MoXuhvYjT1U-YbaUx_ziXLKu2zsvZWjM_0jw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Oct 22, 2013 at 9:55 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> ----- Original Message -----
>>> Hi Evan,
>>>
>>> We did an experiment using the LLVM test suite: we compare the
>>> overhead of using our analysis to the LLVM default, both with -O2
>>> option.
>>
>> It might also be interesting to try with -O3; I don't know if we have any
>> significant vectorizable loops in the test suite with a large number of
>> arrays, but if we do, this kind of analysis should help.
>>
>
> We perform loop vectorization at -O2 now?
>
>
>>
>>>
>>> The overall overhead of compiling the whole test suite using our
>>> analysis is 36.5%.
>>
>> Maybe a good candidate for -fexpensive-optimizations? (or -O4?)
>>
>
> It would also be helpful to know what the execution performance impact is
> to provide context.
>
>
>>
>>> The biggest overhead is observed in
>>> "SingleSource/Benchmarks/Misc/flops-5", where we are 5 times slower:
>>> 0.07s (with our analysis) compared to 0.0133s(default).
>>> This may not be accurate as the compilation time in both cases are
>>> quite small.
>>
>> In my experience, compile-time measurements from a normal test-suite
>> configuration less than 0.1s are too noisy to use.
>>
>>>
>>> Remind that the compilation time is reported by running our analysis
>>> over individual files, the compilation time overhead will be larger
>>> if
>>> we link all individual compilation units together and run the
>>> analysis over the whole application.
>>
>> Yes, LTO tests would be interesting too.
>>
>> Thanks again,
>> Hal
>>
>>>
>>> Regards,
>>> Lian
>>>
>>> On Sat, Oct 19, 2013 at 7:56 AM, Evan Cheng <evan.cheng at apple.com>
>>> wrote:
>>>>
>>>> On Oct 17, 2013, at 10:51 PM, lian li <lianli at gmail.com> wrote:
>>>>
>>>>> Thanks, Chris.
>>>>>
>>>>> We are interested in contributing it to LLVM itself. Our manager
>>>>> agrees to commit resources for maintenance needs if it is accepted
>>>>> by
>>>>> the community.
>>>>
>>>> This is great. Please make sure Oracle legal sign off on explicitly
>>>> granting LLVM the use of the patents associated with the work.
>>>>
>>>> On the compile time front, can you do a comparison with the LLVM
>>>> default and your new AA? You can just build the LLVM test suite.
>>>>
>>>> Thanks,
>>>>
>>>> Evan
>>>>
>>>>>
>>>>> Regards,
>>>>> Lian
>>>>>
>>>>> On Fri, Oct 18, 2013 at 3:43 PM, Chris Lattner
>>>>> <clattner at apple.com> wrote:
>>>>>>
>>>>>> On Oct 17, 2013, at 5:20 PM, lian li <lianli at gmail.com> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> This is Lian Li from Oracle Labs in Brisbane Australia.
>>>>>>
>>>>>> We have developed a precise and highly efficient pointer analysis
>>>>>> framework on top of LLVM, The approach is flow, context, and
>>>>>> field
>>>>>> sensitive, details are described in the two papers below:
>>>>>>
>>>>>> "Boosting the performance of flow-sensitive points-to analysis
>>>>>> using
>>>>>> value flow" (in ESEC-FSE 2011), and
>>>>>> "Precise and scalable context-sensitive pointer analysis via
>>>>>> value
>>>>>> flow graph" (in ISMM 2013).
>>>>>>
>>>>>> The analysis was initially developed for the purpose of bug
>>>>>> checking,
>>>>>> and is now extended to support compiler optimizations. We have
>>>>>> tested
>>>>>> it with existing compiler optimizations in LLVM, and have seen
>>>>>> promising results.
>>>>>>
>>>>>> We are now considering to make this analysis available to the
>>>>>> LLVM
>>>>>> community, and contribute resources for future maintenance needs,
>>>>>> provided that there is enough interest. We think that a new
>>>>>> precise
>>>>>> pointer analysis in LLVM can enable more new optimization and
>>>>>> analysis
>>>>>> techniques to be developed in LLVM.
>>>>>>
>>>>>> Any people interested in seeing a new precise pointer analysis in
>>>>>> LLVM?
>>>>>>
>>>>>>
>>>>>> This sounds very interesting. Even if it isn't fast enough to be
>>>>>> used with
>>>>>> (for example) clang -O2 or -O3, having such a precise analysis
>>>>>> would be a
>>>>>> great baseline for doing other alias analysis work.
>>>>>>
>>>>>> Are you interested in contributing this to LLVM itself, or just
>>>>>> asking if
>>>>>> people would be interested to see the code in some other form?
>>>>>>
>>>>>> -Chris
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> // Copyright @ 2011 Authorized by ** LIAN LI **
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>
>>>
>>>
>>> --
>>> // Copyright @ 2011 Authorized by ** LIAN LI **
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131022/0ea595b6/attachment-0001.html>
>
> ------------------------------
>
> Message: 12
> Date: Tue, 22 Oct 2013 20:16:35 +0300
> From: Yaron Keren <yaron.keren at gmail.com>
> To: "Kaylor, Andrew" <andrew.kaylor at intel.com>
> Cc: "<llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/
> ELF codegen?
> Message-ID:
> <CANa4zJpYxuvmFTqmE1JTvafnj78FZ72wEdY_bXHck1QS7m+veA at mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit.
> The target which is i686-pc-mingw32-elf so I can use the ELF dynamic
> loader.
> Code model, relocation model and and memory manager are whatever default
> for this - did not modify.
>
> The Module comes from clang. The source is 1000 or more lines repeating C++
> code in one big function:
>
> A+1;
> A*B.t();
>
> where A and B are matrices from Armadillo http://arma.sourceforge.net/.
> This a stress and performance test due to the large number of EH and
> temporary objects created.
>
> I am using the Engine Builder and MCJIT unmodified (except the
> multi-modules patches which are not relevant as there is only one module)
> like this:
>
> OwningPtr<llvm::ExecutionEngine> EE(llvm::EngineBuilder(M)
> .setErrorStr(&Error)
> .setUseMCJIT(true)
> .create());
>
> to run the function either
>
> llvm::Function *F = M->getFunction(Name);
> void *FN = EE->getPointerToFunction(F);
> or
> uint64_t FN = EE->getFunctionAddress(Name);
>
> followed by
>
> ((void (*)())FN)();
> or
> EE->runFunction(F, std::vector<llvm::GenericValue>());
>
> all work the same with smaller about 1000 lines of the above code module
> and crash the same with more code. The call stack is unhelpful Visual C++
> says: Frames below may be incorrect and/or missing which indicates a real
> problem with it. I have tried to provide less stack space (default is 10M)
> for the compiled program without any change.
>
> Yaron
>
>
>
> 2013/10/22 Kaylor, Andrew <andrew.kaylor at intel.com>
>
>> I?m not aware of such a limitation.****
>>
>> ** **
>>
>> What architecture, code model and relocation model are you using? Are you
>> using the SectionMemoryManager?****
>>
>> ** **
>>
>> -Andy****
>>
>> ** **
>>
>> *From:* Yaron Keren [mailto:yaron.keren at gmail.com]
>> *Sent:* Tuesday, October 22, 2013 8:12 AM
>> *To:* <llvmdev at cs.uiuc.edu>; Kaylor, Andrew
>> *Subject:* Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?***
>> *
>>
>> ** **
>>
>> I'm running in MCJIT a module generated from one C++ function. Every line
>> of the source function uses C++ classes and may throw an exception. As long
>> as there are less than (about) 1000 lines, everything works. With more
>> lines the compiled code crashes when running it, with no sensible stack
>> trace.****
>>
>> ** **
>>
>> Is there any kind of hard-coded size limitation in MCJIT / ELF Dynamic
>> Linker / ELF codegen / number of EH states in a function ? ****
>>
>> ** **
>>
>> I did browse the code but could not find anything obvious. ****
>>
>> ** **
>>
>> Yaron****
>>
>> ** **
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131022/f4d24c2d/attachment-0001.html>
>
> ------------------------------
>
> Message: 13
> Date: Tue, 22 Oct 2013 12:29:08 -0500 (CDT)
> From: Hal Finkel <hfinkel at anl.gov>
> To: Chandler Carruth <chandlerc at google.com>
> Cc: lian li <lianli at gmail.com>, LLVM Developers Mailing List
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Contribute a new precise pointer analysis to
> LLVM
> Message-ID:
> <394990083.5235580.1382462948069.JavaMail.root at alcf.anl.gov>
> Content-Type: text/plain; charset=utf-8
>
> ----- Original Message -----
>>
>>
>>
>> On Tue, Oct 22, 2013 at 9:55 AM, Hal Finkel < hfinkel at anl.gov >
>> wrote:
>>
>>
>>
>> ----- Original Message -----
>>> Hi Evan,
>>>
>>> We did an experiment using the LLVM test suite: we compare the
>>> overhead of using our analysis to the LLVM default, both with -O2
>>> option.
>>
>> It might also be interesting to try with -O3; I don't know if we have
>> any significant vectorizable loops in the test suite with a large
>> number of arrays, but if we do, this kind of analysis should help.
>>
>>
>>
>> We perform loop vectorization at -O2 now?
>
> You're right, we do. I had forgotten about that. The code in Driver/Tools.cpp now reads:
>
> /// \brief Vectorize at all optimization levels greater than 1 except for -Oz.
> static bool shouldEnableVectorizerAtOLevel(const ArgList &Args) {
>
> (and we SLP vectorize at -O1 too)
>
> -Hal
>
>>
>>
>>
>>
>>>
>>> The overall overhead of compiling the whole test suite using our
>>> analysis is 36.5%.
>>
>> Maybe a good candidate for -fexpensive-optimizations? (or -O4?)
>>
>>
>>
>> It would also be helpful to know what the execution performance
>> impact is to provide context.
>>
>>
>>
>>
>>> The biggest overhead is observed in
>>> "SingleSource/Benchmarks/Misc/flops-5", where we are 5 times
>>> slower:
>>> 0.07s (with our analysis) compared to 0.0133s(default).
>>> This may not be accurate as the compilation time in both cases are
>>> quite small.
>>
>> In my experience, compile-time measurements from a normal test-suite
>> configuration less than 0.1s are too noisy to use.
>>
>>
>>>
>>> Remind that the compilation time is reported by running our
>>> analysis
>>> over individual files, the compilation time overhead will be larger
>>> if
>>> we link all individual compilation units together and run the
>>> analysis over the whole application.
>>
>> Yes, LTO tests would be interesting too.
>>
>> Thanks again,
>> Hal
>>
>>
>>
>>>
>>> Regards,
>>> Lian
>>>
>>> On Sat, Oct 19, 2013 at 7:56 AM, Evan Cheng < evan.cheng at apple.com
>>>>
>>> wrote:
>>>>
>>>> On Oct 17, 2013, at 10:51 PM, lian li < lianli at gmail.com > wrote:
>>>>
>>>>> Thanks, Chris.
>>>>>
>>>>> We are interested in contributing it to LLVM itself. Our manager
>>>>> agrees to commit resources for maintenance needs if it is
>>>>> accepted
>>>>> by
>>>>> the community.
>>>>
>>>> This is great. Please make sure Oracle legal sign off on
>>>> explicitly
>>>> granting LLVM the use of the patents associated with the work.
>>>>
>>>> On the compile time front, can you do a comparison with the LLVM
>>>> default and your new AA? You can just build the LLVM test suite.
>>>>
>>>> Thanks,
>>>>
>>>> Evan
>>>>
>>>>>
>>>>> Regards,
>>>>> Lian
>>>>>
>>>>> On Fri, Oct 18, 2013 at 3:43 PM, Chris Lattner
>>>>> < clattner at apple.com > wrote:
>>>>>>
>>>>>> On Oct 17, 2013, at 5:20 PM, lian li < lianli at gmail.com >
>>>>>> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> This is Lian Li from Oracle Labs in Brisbane Australia.
>>>>>>
>>>>>> We have developed a precise and highly efficient pointer
>>>>>> analysis
>>>>>> framework on top of LLVM, The approach is flow, context, and
>>>>>> field
>>>>>> sensitive, details are described in the two papers below:
>>>>>>
>>>>>> "Boosting the performance of flow-sensitive points-to analysis
>>>>>> using
>>>>>> value flow" (in ESEC-FSE 2011), and
>>>>>> "Precise and scalable context-sensitive pointer analysis via
>>>>>> value
>>>>>> flow graph" (in ISMM 2013).
>>>>>>
>>>>>> The analysis was initially developed for the purpose of bug
>>>>>> checking,
>>>>>> and is now extended to support compiler optimizations. We have
>>>>>> tested
>>>>>> it with existing compiler optimizations in LLVM, and have seen
>>>>>> promising results.
>>>>>>
>>>>>> We are now considering to make this analysis available to the
>>>>>> LLVM
>>>>>> community, and contribute resources for future maintenance
>>>>>> needs,
>>>>>> provided that there is enough interest. We think that a new
>>>>>> precise
>>>>>> pointer analysis in LLVM can enable more new optimization and
>>>>>> analysis
>>>>>> techniques to be developed in LLVM.
>>>>>>
>>>>>> Any people interested in seeing a new precise pointer analysis
>>>>>> in
>>>>>> LLVM?
>>>>>>
>>>>>>
>>>>>> This sounds very interesting. Even if it isn't fast enough to
>>>>>> be
>>>>>> used with
>>>>>> (for example) clang -O2 or -O3, having such a precise analysis
>>>>>> would be a
>>>>>> great baseline for doing other alias analysis work.
>>>>>>
>>>>>> Are you interested in contributing this to LLVM itself, or just
>>>>>> asking if
>>>>>> people would be interested to see the code in some other form?
>>>>>>
>>>>>> -Chris
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> // Copyright @ 2011 Authorized by ** LIAN LI **
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>
>>>
>>>
>>> --
>>> // Copyright @ 2011 Authorized by ** LIAN LI **
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
>
> ------------------------------
>
> _______________________________________________
> LLVMdev mailing list
> LLVMdev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> End of LLVMdev Digest, Vol 112, Issue 59
> ****************************************
More information about the llvm-dev
mailing list