Displaying 6 results from an estimated 6 matches for "183_equake".
2014 Sep 14
2
[LLVMdev] Testing the new CFL alias analysis
...On Sep 12, 2014, at 1:27 AM, Jiangning Liu <liujiangning1 at gmail.com> wrote:
> Hi Hal,
>
> I run on SPEC2000 on cortex-a57(AArch64), and got the following results,
>
> (It is to measure run-time reduction, and negative is better performance)
>
> spec.cpu2000.ref.183_equake 33.77%
> spec.cpu2000.ref.179_art 13.44%
> spec.cpu2000.ref.256_bzip2 7.80%
> spec.cpu2000.ref.186_crafty 3.69%
> spec.cpu2000.ref.175_vpr 2.96%
> spec.cpu2000.ref.176_gcc 1.77%
> spec.cpu2000.ref.252_eon 1.77%
> spec.cpu2000.ref.254_gap 1.19%
> spec.cpu2000.ref.197_parser 1...
2014 Sep 03
2
[LLVMdev] Testing the new CFL alias analysis
Hello everyone,
One of Google's summer interns, George Burgess IV, created an implementation of the CFL pointer-aliasing analysis algorithm, and this has now been added to LLVM trunk. Now we should determine whether it is worthwhile adding this to the default optimization pipeline. For ease of testing, I've added the command line option -use-cfl-aa which will cause the CFL analysis to be
2014 Sep 15
2
[LLVMdev] Testing the new CFL alias analysis
...t;> wrote:
>>
>>
>>
>> Hi Hal,
>>
>> I run on SPEC2000 on cortex-a57(AArch64), and got the following
>> results,
>>
>> (It is to measure run-time reduction, and negative is better
>> performance)
>>
>> spec.cpu2000.ref.183_equake 33.77%
>> spec.cpu2000.ref.179_art 13.44%
>> spec.cpu2000.ref.256_bzip2 7.80%
>> spec.cpu2000.ref.186_crafty 3.69%
>> spec.cpu2000.ref.175_vpr 2.96%
>> spec.cpu2000.ref.176_gcc 1.77%
>> spec.cpu2000.ref.252_eon 1.77%
>> spec.cpu2000.ref.254_gap 1.19%
>&g...
2014 Sep 16
2
[LLVMdev] Testing the new CFL alias analysis
...g Liu < liujiangning1 at gmail.com
>
>
> wrote:
>
>
>
> Hi Hal,
>
> I run on SPEC2000 on cortex-a57(AArch64), and got the following
> results,
>
> (It is to measure run-time reduction, and negative is better
> performance)
>
> spec.cpu2000.ref.183_equake 33.77%
> spec.cpu2000.ref.179_art 13.44%
> spec.cpu2000.ref.256_bzip2 7.80%
> spec.cpu2000.ref.186_crafty 3.69%
> spec.cpu2000.ref.175_vpr 2.96%
> spec.cpu2000.ref.176_gcc 1.77%
> spec.cpu2000.ref.252_eon 1.77%
> spec.cpu2000.ref.254_gap 1.19%
> spec.cpu2000.ref.197_parser 1...
2015 Feb 26
5
[LLVMdev] [RFC] AArch64: Should we disable GlobalMerge?
Hi all,
I've started looking at the GlobalMerge pass, enabled by default on
ARM and AArch64. I think we should reconsider that, at least for
AArch64.
As is, the pass just merges all globals together, in groups of 4KB
(AArch64, 128B on ARM).
At the time it was enabled, the general thinking was "it's almost
free, it doesn't affect performance much, we might as well use it".
2011 Dec 01
1
[LLVMdev] [llvm-testresults] bwilson__llvm-gcc_PROD__i386 nightly tester results
..._folding.compile=on>
> 2.50% 2.5123 2.5751 0.0094
> MultiSource/Benchmarks/PAQ8p/paq8p.compile
> <http://llvm.org/perf/db_default/simple/nts/380/graph?pset.0=on&test.MultiSource%2FBenchmarks%2FPAQ8p%2Fpaq8p.compile=on>
> 2.50% 2.0767 2.1286 0.0040
> External/SPEC/CFP2000/183_equake/183_equake.compile
> <http://llvm.org/perf/db_default/simple/nts/380/graph?pset.0=on&test.External%2FSPEC%2FCFP2000%2F183_equake%2F183_equake.compile=on>
> 2.43% 0.3781 0.3873 0.0010
> MultiSource/Benchmarks/Prolangs-C/cdecl/cdecl.compile
> <http://llvm.org/perf/db_default/...