[LLVMdev] Please benchmark new x86 vector shuffle lowering, planning to make it the default very soon!
Quentin Colombet
qcolombet at apple.com
Tue Sep 9 15:01:11 PDT 2014
Hi Chandler,
Here is a test case for the biggest offender (oourafft.c).
To reproduce:
llc -mcpu=core-avx-i -x86-experimental-vector-shuffle-lowering=true repro.ll
llc -mcpu=core-avx-i -x86-experimental-vector-shuffle-lowering=false repro.ll
The main problem is that we miss:
vmovsd (%rdi,%rcx,8), %xmm2
vmovlhps %xmm2, %xmm2, %xmm2 ## xmm2 = xmm2[0,0]
=>
vmovddup (%rdi,%rcx,8), %xmm2
I do not know how problematic is that (it seems we catch up on the performance with just the previous transformation), but we also miss:
vsubpd %xmm1, %xmm0, %xmm2
vaddpd %xmm1, %xmm0, %xmm0
vshufpd $2, %xmm0, %xmm2, %xmm0 ## xmm0 = xmm2[0],xmm0[1]
=>
vaddsubpd %xmm1, %xmm0, %xmm0
I’ll look into the other regressions.
Thanks,
-Quentin
> On Sep 9, 2014, at 1:59 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>
>
>> On Sep 9, 2014, at 1:47 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote:
>>
>>
>>
>> On Tue, Sep 9, 2014 at 12:53 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:
>> Hi Chandler,
>>
>> I had observed some improvements and regressions with the new lowering.
>>
>> Here are the numbers for an Ivy Bridge machine fixed at 2900MHz.
>>
>> I’ll look into the regressions to provide test cases.
>>
>> ** Numbers **
>>
>> Smaller is better. Only reported tests that run for at least one second.
>> Reference is the default lowering, Test is the new lowering.
>> The Os numbers are overall neutral, but the O3 numbers mainly expose regressions.
>>
>> Note: I can attach the raw numbers if you want.
>>
>> That would be great. Please do.
>
> Alright, here they are :).
>
> base-perf-Ox.txt: runtime for the default lowering.
> new-perf-Ox.txt: runtime for the new lowering.
>
> Each line in those files has the following format:
> <unit> <benchmark> <perf number>
>
> The units are:
> - min: Minimum of the 7 runs.
> - max: Maximum of the 7 runs.
> - avg: Average of the 7 runs.
> - total: Total of the 7 runs.
> - med: Median of the 7 runs.
> - SD: Standard deviation of the 7 runs.
> - SD%: Standard deviation of the7 runs in percentage.
>
> -Quentin
> <base-perf-O3.txt>
> <base-perf-Os.txt>
> <new-perf-O3.txt>
> <new-perf-Os.txt>
>
>>
>> -- Sean Silva
>>
>>
>> * Os *
>> Benchmark_ID Reference Test Expansion Percent
>> -------------------------------------------------------------------------------
>> External/Nurbs/nurbs 2.3302 2.3122 0.99 -1%
>> External/SPEC/CFP2000/183.equake/183.eq 3.2606 3.2419 0.99 -1%
>> External/SPEC/CFP2006/447.dealII/447.de <http://447.de/> 16.4638 16.1313 0.98 -2%
>> External/SPEC/CFP2006/470.lbm/470.lbm 2.0159 1.9931 0.99 -1%
>> External/SPEC/CINT2000/164.gzip/164.gzi 8.7611 8.6981 0.99 -1%
>> External/SPEC/CINT2006/456.hmmer/456.hm <http://456.hm/> 2.5674 2.5819 1.01 +1%
>> External/SPEC/CINT2006/462.libquantum/4 1.2924 1.347 1.04 +4%
>> MultiSource/Benchmarks/TSVC/CrossingThr 2.4703 2.4852 1.01 +1%
>> MultiSource/Benchmarks/TSVC/LoopRerolli 2.6611 2.5668 0.96 -4%
>> MultiSource/Benchmarks/mafft/pairlocala 24.676 24.5372 0.99 -1%
>> SingleSource/Benchmarks/Adobe-C++/simpl 1.0579 1.1048 1.04 +4%
>> SingleSource/Benchmarks/Linpack/linpack 4.2817 4.3298 1.01 +1%
>> SingleSource/Benchmarks/Misc-C++/stepan 4.1821 4.226 1.01 +1%
>> SingleSource/Benchmarks/Misc/oourafft 3.0305 3.1777 1.05 +5%
>> -------------------------------------------------------------------------------
>> Min (14) - - 0.96 -
>> -------------------------------------------------------------------------------
>> Max (14) - - 1.05 -
>> -------------------------------------------------------------------------------
>> Sum (14) 79 79 1 +0%
>> -------------------------------------------------------------------------------
>> A.Mean (14) - - 1.01 +1%
>> -------------------------------------------------------------------------------
>> G.Mean 2 (14) - - 1.01 +1%
>> -------------------------------------------------------------------------------
>>
>> * O3 *
>> Benchmark_ID Reference Test Expansion Percent
>> -------------------------------------------------------------------------------
>> External/Nurbs/nurbs 2.2322 2.2131 0.99 -1%
>> External/Povray/povray 2.2638 2.2762 1.01 +1%
>> External/SPEC/CFP2000/177.mesa/177.mesa 1.6675 1.6828 1.01 +1%
>> External/SPEC/CFP2000/188.ammp/188.ammp 10.9309 11.1191 1.02 +2%
>> External/SPEC/CFP2006/433.milc/433.milc 6.9214 7.1696 1.04 +4%
>> External/SPEC/CINT2000/164.gzip/164.gzi 8.5327 8.8114 1.03 +3%
>> External/SPEC/CINT2000/186.crafty/186.c 4.1266 4.16 1.01 +1%
>> External/SPEC/CINT2000/253.perlbmk/253. 5.6991 5.7309 1.01 +1%
>> External/SPEC/CINT2000/256.bzip2/256.bz <http://256.bz/> 6.7917 6.8763 1.01 +1%
>> External/SPEC/CINT2006/400.perlbench/40 6.243 6.1464 0.98 -2%
>> External/SPEC/CINT2006/401.bzip2/401.bz <http://401.bz/> 2.095 2.0588 0.98 -2%
>> External/SPEC/CINT2006/462.libquantum/4 1.2 1.2108 1.01 +1%
>> MultiSource/Applications/SIBsim4/SIBsim 2.4547 2.5129 1.02 +2%
>> MultiSource/Benchmarks/Bullet/bullet 4.1687 4.0882 0.98 -2%
>> MultiSource/Benchmarks/TSVC/LinearDepen 3.0389 3.0566 1.01 +1%
>> MultiSource/Benchmarks/TSVC/LinearDepen 2.1298 2.1997 1.03 +3%
>> MultiSource/Benchmarks/TSVC/LoopRerolli 2.6458 2.5552 0.97 -3%
>> MultiSource/Benchmarks/TSVC/Symbolics-f 1.6243 1.6612 1.02 +2%
>> MultiSource/Benchmarks/mafft/pairlocala 23.8979 24.0547 1.01 +1%
>> SingleSource/Benchmarks/Misc/oourafft 3.0374 3.1846 1.05 +5%
>> SingleSource/Benchmarks/SmallPT/smallpt 6.5533 6.6683 1.02 +2%
>> -------------------------------------------------------------------------------
>> Min (21) - - 0.97 -
>> -------------------------------------------------------------------------------
>> Max (21) - - 1.05 -
>> -------------------------------------------------------------------------------
>> Sum (21) 108 109 1.01 -1%
>> -------------------------------------------------------------------------------
>> A.Mean (21) - - 1.01 +1%
>> -------------------------------------------------------------------------------
>> G.Mean 2 (21) - - 1.01 +1%
>> -------------------------------------------------------------------------------
>>
>> Thanks,
>> -Quentin
>>
>>> On Sep 9, 2014, at 6:13 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com <mailto:andrea.dibiagio at gmail.com>> wrote:
>>>
>>> Hi Chandler,
>>>
>>> Thanks for fixing the problem with the insertps mask.
>>>
>>> Generally the new shuffle lowering looks promising, however there are
>>> some cases where the codegen is now worse causing runtime performance
>>> regressions in some of our internal codebase.
>>>
>>> You have already mentioned how the new shuffle lowering is missing
>>> some features; for example, you explicitly said that we currently lack
>>> of SSE4.1 blend support. Unfortunately, this seems to be one of the
>>> main reasons for the slowdown we are seeing.
>>>
>>> Here is a list of what we found so far that we think is causing most
>>> of the slowdown:
>>> 1) shufps is always emitted in cases where we could emit a single
>>> blendps; in these cases, blendps is preferable because it has better
>>> reciprocal throughput (this is true on all modern Intel and AMD cpus).
>>>
>>> Things get worse when it comes to lowering shuffles where the shuffle
>>> mask indices refer to elements from both input vectors in each lane.
>>> For example, a shuffle mask of <0,5,2,7> could be easily lowered into
>>> a single blendps; instead it gets lowered into two shufps
>>> instructions.
>>>
>>> Example:
>>> ;;;
>>> define <4 x float> @foo(<4 x float> %A, <4 x float> %B) {
>>> %1 = shufflevector <4 x float> %A, <4 x float> %B, <4 x i32> <i32 0,
>>> i32 5, i32 2, i32 7>
>>> ret <4 x float> %1
>>> }
>>> ;;;
>>>
>>> llc (-mcpu=corei7-avx):
>>> vblendps $10, %xmm1, %xmm0, %xmm0 # xmm0 = xmm0[0],xmm1[5],xmm0[2],xmm1[7]
>>>
>>> llc -x86-experimental-vector-shuffle-lowering (-mcpu=corei7-avx):
>>> vshufps $-40, %xmm0, %xmm1, %xmm0 # xmm0 = xmm1[0,2],xmm0[1,3]
>>> vshufps $-40, %xmm0, %xmm0, %xmm0 # xmm0[0,2,1,3]
>>>
>>>
>>> 2) On SSE4.1, we should try not to emit an insertps if the shuffle
>>> mask identifies a blend. At the moment the new lowering logic is very
>>> aggressively emitting insertps instead of cheaper blendps.
>>>
>>> Example:
>>> ;;;
>>> define <4 x float> @bar(<4 x float> %A, <4 x float> %B) {
>>> %1 = shufflevector <4 x float> %A, <4 x float> %B, <4 x i32> <i32 4,
>>> i32 5, i32 2, i32 7>
>>> ret <4 x float> %1
>>> }
>>> ;;;
>>>
>>> llc (-mcpu=corei7-avx):
>>> vblendps $11, %xmm0, %xmm1, %xmm0 # xmm0 = xmm0[0,1],xmm1[2],xmm0[3]
>>>
>>> llc -x86-experimental-vector-shuffle-lowering (-mcpu=corei7-avx):
>>> vinsertps $-96, %xmm1, %xmm0, %xmm0 # xmm0 = xmm0[0,1],xmm1[2],xmm0[3]
>>>
>>>
>>> 3) When a shuffle performs an insert at index 0 we always generate an
>>> insertps, while a movss would do a better job.
>>> ;;;
>>> define <4 x float> @baz(<4 x float> %A, <4 x float> %B) {
>>> %1 = shufflevector <4 x float> %A, <4 x float> %B, <4 x i32> <i32 4,
>>> i32 1, i32 2, i32 3>
>>> ret <4 x float> %1
>>> }
>>> ;;;
>>>
>>> llc (-mcpu=corei7-avx):
>>> vmovss %xmm1, %xmm0, %xmm0
>>>
>>> llc -x86-experimental-vector-shuffle-lowering (-mcpu=corei7-avx):
>>> vinsertps $0, %xmm1, %xmm0, %xmm0 # xmm0 = xmm1[0],xmm0[1,2,3]
>>>
>>> I hope this is useful. We would be happy to contribute patches to
>>> improve some of the above cases, but we obviously know that this is
>>> still a work in progress, so we don't want to introduce conflicts with
>>> your work. Please let us know what you think.
>>>
>>> We will keep looking at this and follow up with any further findings.
>>>
>>> Thanks,
>>> Andrea Di Biagio
>>> SN Systems - Sony Computer Entertainment Inc.
>>>
>>> On Mon, Sep 8, 2014 at 6:08 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:
>>>> Hi Chandler,
>>>>
>>>> Forget about that I said.
>>>> It seems I have some weird dependencies in my built system.
>>>> My binaries are out-of-sync.
>>>>
>>>> Let me sort that out, this is likely the problem is already fixed, and I can
>>>> resume the measurements.
>>>>
>>>> Sorry for the noise.
>>>>
>>>> Q.
>>>>
>>>> On Sep 8, 2014, at 9:32 AM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:
>>>>
>>>>
>>>> On Sep 7, 2014, at 8:49 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:
>>>>
>>>> Sure,
>>>>
>>>> Here is the command line:
>>>> clang -cc1 -triple x86_64-apple-macosx -S -disable-free
>>>> -disable-llvm-verifier -main-file-name tmp.i -mrelocation-model pic
>>>> -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu
>>>> core-avx-i -O3 -ferror-limit 19 -fmessage-length 114 -stack-protector 1
>>>> -mstackrealign -fblocks -fencode-extended-block-signature
>>>> -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics
>>>> -vectorize-loops -vectorize-slp -mllvm
>>>> -x86-experimental-vector-shuffle-lowering=true -o tmp.s -x cpp-output tmp.i
>>>>
>>>> This was with trunk 215249.
>>>>
>>>> I meant, r217281.
>>>>
>>>>
>>>> Thanks,
>>>> -Quentin
>>>>
>>>> <tmp.i>
>>>>
>>>> On Sep 6, 2014, at 4:27 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
>>>>
>>>> I've run the SingleSource test suite for core-avx-i and have no failures
>>>> here so a preprocessed file + commandline would be very useful if this
>>>> reproduces for you still.
>>>>
>>>> On Sat, Sep 6, 2014 at 4:07 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>>
>>>> wrote:
>>>>>
>>>>> I'm having trouble reproducing this. I'm trying to get LNT to actually
>>>>> run, but manually compiling the given source file didn't reproduce it for
>>>>> me.
>>>>>
>>>>> It might have been fixed recently (although I'd be surprised if so), but
>>>>> it would help to get the actual command line for which compiling this file
>>>>> in the test suite failed.
>>>>>
>>>>> -Chandler
>>>>>
>>>>> On Fri, Sep 5, 2014 at 4:36 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>>
>>>>> wrote:
>>>>>>
>>>>>> Hi Chandler,
>>>>>>
>>>>>> While doing the performance measurement on a Ivy Bridge, I ran into
>>>>>> compile time errors.
>>>>>>
>>>>>> I saw a bunch of “cannot select" in the LLVM test suite with
>>>>>> -march=core-avx-i.
>>>>>> E.g., SingleSource/UnitTests/Vector/SSE/sse.isamax.c is failing at O3
>>>>>> -march=core-avx-i with:
>>>>>> fatal error: error in backend: Cannot select: 0x7f91b99a6420: v4i32 =
>>>>>> bitcast 0x7f91b99b0e10 [ORD=3] [ID=27]
>>>>>> 0x7f91b99b0e10: v4i64 = insert_subvector 0x7f91b99a7210,
>>>>>> 0x7f91b99a6d68, 0x7f91b99ace70 [ORD=2] [ID=25]
>>>>>> 0x7f91b99a7210: v4i64 = undef [ID=15]
>>>>>> 0x7f91b99a6d68: v2i64 = scalar_to_vector 0x7f91b99ab840 [ORD=2]
>>>>>> [ID=23]
>>>>>> 0x7f91b99ab840: i64 = AssertZext 0x7f91b99acc60, 0x7f91b99ac738
>>>>>> [ORD=2] [ID=20]
>>>>>> 0x7f91b99acc60: i64,ch = CopyFromReg 0x7f91b8d52820,
>>>>>> 0x7f91b99a3a10 [ORD=2] [ID=16]
>>>>>> 0x7f91b99a3a10: i64 = Register %vreg68 [ID=1]
>>>>>> 0x7f91b99ace70: i64 = Constant<0> [ID=3]
>>>>>> In function: isamax0
>>>>>> clang: error: clang frontend command failed with exit code 70 (use -v to
>>>>>> see invocation)
>>>>>> clang version 3.6.0 (215249)
>>>>>> Target: x86_64-apple-darwin14.0.0
>>>>>>
>>>>>> For some reason, I cannot reproduce the problem with the test case that
>>>>>> clang gives me using -emit-llvm. Since the source is public, I guess you can
>>>>>> try to reproduce on your side.
>>>>>> Indeed, if you run the test-suite with -march=core-avx-i you’ll likely
>>>>>> see all those failures.
>>>>>>
>>>>>> Let me know if you cannot and I’ll try harder to produce a test case.
>>>>>>
>>>>>> Note: This is the same failure all over the place, i.e., cannot select a
>>>>>> bit cast from various types to v4i32 or v4i64.
>>>>>>
>>>>>> Thanks,
>>>>>> -Quentin
>>>>>>
>>>>>>
>>>>>> On Sep 5, 2014, at 11:09 AM, Robert Lougher <rob.lougher@
>>>>>>
>>>>>> gmail.com <http://gmail.com/>> wrote:
>>>>>>
>>>>>> Hi Chandler,
>>>>>>
>>>>>> On 5 September 2014 17:38, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 5, 2014 at 9:32 AM, Robert Lougher <rob.lougher at gmail.com <mailto:rob.lougher at gmail.com>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Unfortunately, another team, while doing internal testing has seen the
>>>>>> new path generating illegal insertps masks. A sample here:
>>>>>>
>>>>>> vinsertps $256, %xmm0, %xmm13, %xmm4 # xmm4 = xmm0[0],xmm13[1,2,3]
>>>>>> vinsertps $256, %xmm1, %xmm0, %xmm6 # xmm6 = xmm1[0],xmm0[1,2,3]
>>>>>> vinsertps $256, %xmm13, %xmm1, %xmm7 # xmm7 = xmm13[0],xmm1[1,2,3]
>>>>>> vinsertps $416, %xmm1, %xmm4, %xmm14 # xmm14 =
>>>>>> xmm4[0,1],xmm1[2],xmm4[3]
>>>>>> vinsertps $416, %xmm13, %xmm6, %xmm13 # xmm13 =
>>>>>> xmm6[0,1],xmm13[2],xmm6[3]
>>>>>> vinsertps $416, %xmm0, %xmm7, %xmm0 # xmm0 =
>>>>>> xmm7[0,1],xmm0[2],xmm7[3]
>>>>>>
>>>>>> We'll continue to look into this and do additional testing.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Interesting. Let me know if you get a test case. The insertps code path
>>>>>> was
>>>>>> added recently though and has been much less well tested. I'll start fuzz
>>>>>> testing it and should hopefully uncover the bug.
>>>>>>
>>>>>>
>>>>>> Here's two small test cases. Hope they are of use.
>>>>>>
>>>>>> Thanks,
>>>>>> Rob.
>>>>>>
>>>>>> ------
>>>>>> define <4 x float> @test(<4 x float> %xyzw, <4 x float> %abcd) {
>>>>>> %1 = extractelement <4 x float> %xyzw, i32 0
>>>>>> %2 = insertelement <4 x float> undef, float %1, i32 0
>>>>>> %3 = insertelement <4 x float> %2, float 0.000000e+00, i32 1
>>>>>> %4 = shufflevector <4 x float> %3, <4 x float> %xyzw, <4 x i32> <i32
>>>>>> 0, i32 1, i32 6, i32 undef>
>>>>>> %5 = shufflevector <4 x float> %4, <4 x float> %abcd, <4 x i32> <i32
>>>>>> 0, i32 1, i32 2, i32 4>
>>>>>> ret <4 x float> %5
>>>>>> }
>>>>>>
>>>>>> define <4 x float> @test2(<4 x float> %xyzw, <4 x float> %abcd) {
>>>>>> %1 = shufflevector <4 x float> %xyzw, <4 x float> %abcd, <4 x i32>
>>>>>> <i32 0, i32 undef, i32 2, i32 4>
>>>>>> %2 = shufflevector <4 x float> <float undef, float 0.000000e+00,
>>>>>> float undef, float undef>, <4 x float> %1, <4 x i32> <i32 4, i32 1,
>>>>>> i32 6, i32 7>
>>>>>> ret <4 x float> %2
>>>>>> }
>>>>>>
>>>>>>
>>>>>> llc -march=x86-64 -mattr=+avx test.ll -o -
>>>>>>
>>>>>> test: # @test
>>>>>> vxorps %xmm2, %xmm2, %xmm2
>>>>>> vmovss %xmm0, %xmm2, %xmm2
>>>>>> vblendps $4, %xmm0, %xmm2, %xmm0 # xmm0 = xmm2[0,1],xmm0[2],xmm2[3]
>>>>>> vinsertps $48, %xmm1, %xmm0, %xmm0 # xmm0 = xmm0[0,1,2],xmm1[0]
>>>>>> retl
>>>>>>
>>>>>> test2: # @test2
>>>>>> vinsertps $48, %xmm1, %xmm0, %xmm0 # xmm0 = xmm0[0,1,2],xmm1[0]
>>>>>> vxorps %xmm1, %xmm1, %xmm1
>>>>>> vblendps $13, %xmm0, %xmm1, %xmm0 # xmm0 =
>>>>>> xmm0[0],xmm1[1],xmm0[2,3]
>>>>>> retl
>>>>>>
>>>>>> llc -march=x86-64 -mattr=+avx
>>>>>> -x86-experimental-vector-shuffle-lowering test.ll -o -
>>>>>>
>>>>>> test: # @test
>>>>>> vinsertps $270, %xmm0, %xmm0, %xmm2 # xmm2 = xmm0[0],zero,zero,zero
>>>>>> vinsertps $416, %xmm0, %xmm2, %xmm0 # xmm0 =
>>>>>> xmm2[0,1],xmm0[2],xmm2[3]
>>>>>> vinsertps $304, %xmm1, %xmm0, %xmm0 # xmm0 = xmm0[0,1,2],xmm1[0]
>>>>>> retl
>>>>>>
>>>>>> test2: # @test2
>>>>>> vinsertps $304, %xmm1, %xmm0, %xmm0 # xmm0 = xmm0[0,1,2],xmm1[0]
>>>>>> vxorps %xmm1, %xmm1, %xmm1
>>>>>> vinsertps $336, %xmm1, %xmm0, %xmm0 # xmm0 =
>>>>>> xmm0[0],xmm1[1],xmm0[2,3]
>>>>>> retl
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140909/565be8f4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repro.ll
Type: application/octet-stream
Size: 2265 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140909/565be8f4/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140909/565be8f4/attachment-0001.html>
More information about the llvm-dev
mailing list