Displaying 20 results from an estimated 69 matches for "xalancbmk".
2017 Feb 18
2
[RFC] Using Intel MPX to harden SafeStack
...4.h264ref|701.37|682.13|683.41|699.93 |
+--------------+---------+---------+---------+-------+
|471.omnetpp|397.04|407.38|407.33|411.36 |
+--------------+---------+---------+---------+-------+
|473.astar|611.51|610.46|610.19|624.78 |
+--------------+---------+---------+---------+-------+
|483.xalancbmk |291.66|295.61|296.42|298.29 |
+--------------+---------+---------+---------+-------+
|SUM |6058.32|6093.10|6094.62|6249.16|
+--------------+---------+---------+---------+-------+
These runtimes are estimates as benchmark runs for research purposes
built with patched/experimental compilers ca...
2020 Aug 18
3
[RFC] Switching to MemorySSA-backed Dead Store Elimination (aka cross-bb DSE)
> On Aug 18, 2020, at 16:59, Michael Kruse <llvmdev at meinersbur.de> wrote:
>
> Thanks for all the work. The reductions in stores look promising. Do you also have performance numbers how much this improves the execution time? Did you observe any regressions where MSSA resulted in fewer removed stores?
I did not gather numbers for execution time yet, but I’ll try to share some
2017 May 18
6
Enable vectorizer-maximize-bandwidth by default?
...ec/2006/fp/C/433.milc 24.54 -0.76%
spec/2006/fp/C/470.lbm 41.08 +0.26%
spec/2006/fp/C/482.sphinx3 47.58 -0.99%
spec/2006/int/C++/471.omnetpp 22.06 +1.87%
spec/2006/int/C++/473.astar 22.65 -0.12%
spec/2006/int/C++/483.xalancbmk 33.69 +4.97%
spec/2006/int/C/400.perlbench 33.43 +1.70%
spec/2006/int/C/401.bzip2 23.02 -0.19%
spec/2006/int/C/403.gcc 32.57 -0.43%
spec/2006/int/C/429.mcf 40.35 +0.27%
spec/2006/int/C/445.gobmk 26.96 +0...
2016 Mar 29
2
[CodeGen] CodeSize - TailMerging and BlockPlacement
...small improvement (1%-3%).
473.astar -7
401.bzip2 -110
403.gcc -13,006
445.gobmk -1,716
464.h264ref -684
456.hmmer -391
462.libquantum -4
429.mcf -4
471.omnetpp -1,980
400.perlbench -4,176
458.sjeng -338
450.soplex -395
483.xalancbmk -4,183
447.dealII -186
433.milc -34
444.namd -104
453.povray -1,785
482.sphinx3 -112
I propose to factor out the relevant code from BranchFolding into a
utility, and call it from BlockPlacement whenever the layout is changed.
It is similar to D18226 and D184...
2013 Oct 01
0
[LLVMdev] Proposal: type uniquing of debug info for LTO
...------------
> Problem:
> A single class can be used in multiple source files and the DI (Debug Info) class is included in multiple bc files. The duplication of
> class definitions causes blow-up in # of MDNodes, # of DIEs, leading to large memory requirement.
>
> As an example, SPEC xalancbmk requires 7GB of memory when compiled with -flto -g.
> With a preliminary implementation of type uniquing, the memory usage will be down to 2GB.
This is awesome! :-)
> In order to unique types, we have to break cycles in the MDNodes.
Sorry I missed this email earlier, but do we really need...
2012 Apr 05
3
[LLVMdev] Implementing minimal debug info (-g1?) for Clang
...quot;-g1" flags.
(See this patch at
http://old.nabble.com/-patch--Add-new--gmlt-option-for-min.-debug-info-with-line-tables-(issue4440072)-td31482851.html
or http://codereview.appspot.com/4440072). This patch is used in Google for
about 2 years already.
I get the following binary sizes of 483.xalancbmk benchmark from SPEC 2006
(clang from trunk vs. gcc 4.6.x with Google patches):
11026073 Xalan_base.clang_O0
45882529 Xalan_base.clang_O0_g
11079688 Xalan_base.gcc_O0
16437776 Xalan_base.gcc_O0_gmlt
54221056 Xalan_base.gcc_O0_g
WDYT of implementing similar option in Clang? Clearly, there are two
op...
2016 Feb 04
2
Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)
...cesses. In the
> future, I will analyze how different flags affect ASan / SoftBoundCETS
> / gcc-mpx / icc-mpx.
> I will also use a set of microbenchmarks/benchmarks (e.g., RIPE) to
> test the protection provided.
>
> > SPEC2006 is well know so it could be useful. Especially 483.xalancbmk
> > Besides, maybe you could take something that is not strictly a benchmark.
> > E.g. take pdfium_test (https://pdfium.googlesource.com/pdfium/) and feed
> > several large pdf files to it.
>
> Thanks, I will report the SPEC2006 numbers as well.
>
>
Note that SPEC2006...
2014 Feb 21
12
[LLVMdev] asan coverage
>
>
>
> We may need some additional info.
What kind of additional info?
> I haven't put a ton of thought into
> this, but I'm hoping we can either (a) use debug info as is or add some
> extra (valid) debug info to support this, or (b) add an extra
> debug-info-like section to instrumented binaries with the information we
> need.
>
I'd try this data
2016 Feb 03
2
Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)
...I will write an update here when it's
> done. Please tell me if anyone is interested in any specific
> benchmarks (I want to test PARSEC and some case-studies: PostgreSQL,
> Memcached, SQLite3). Any feedback is welcome.
>
SPEC2006 is well know so it could be useful. Especially 483.xalancbmk
Besides, maybe you could take something that is not strictly a benchmark.
E.g. take pdfium_test (https://pdfium.googlesource.com/pdfium/) and feed
several large pdf files to it.
>
> On Thu, Jan 28, 2016 at 8:29 PM, Kostya Serebryany <kcc at google.com> wrote:
> > I've recent...
2013 Jun 20
9
[LLVMdev] Proposal: type uniquing of debug info for LTO
...d Eric.
---------------------------
Problem:
A single class can be used in multiple source files and the DI (Debug Info) class is included in multiple bc files. The duplication of
class definitions causes blow-up in # of MDNodes, # of DIEs, leading to large memory requirement.
As an example, SPEC xalancbmk requires 7GB of memory when compiled with -flto -g.
With a preliminary implementation of type uniquing, the memory usage will be down to 2GB.
In order to unique types, we have to break cycles in the MDNodes.
A simple struct definition
struct Base {
int a;
};
can cause cycles in MDNodes:
!12 = me...
2010 Feb 15
0
[LLVMdev] Measurements of the new inlinehint attribute
...um/462.libquantum 1.08% -20.22% 146.24% -7.26%
SPEC/CINT2006/464.h264ref/464.h264ref 0.00% -0.30% 9.22% 0.72%
SPEC/CINT2006/471.omnetpp/471.omnetpp 2.78% 1.92% 67.24% 3.92%
SPEC/CINT2006/473.astar/473.astar 4.59% 6.61% 12.90% -0.87%
SPEC/CINT2006/483.xalancbmk/483.xalancbmk 4.29% 0.00% 34.72% 0.00%
SPEC/CINT95/099.go/099.go 0.00% -3.13% 46.93% 0.00%
SPEC/CINT95/124.m88ksim/124.m88ksim 0.06% 0.00% 11.62% 50.00%
SPEC/CINT95/126.gcc/126.gcc 0.24% 0.00% 36.70% 0.00%
SPEC/CINT95/129.com...
2018 Nov 03
2
llvm bug 36466 fix
Hi Dave
I am not going to access any hardware. I am using clang to analysis the ARM
binaries. The binary is 483.xalancbmk in CPU SPEC2006. When I use the
optimization O0, no crash will occur. The crash occurs when I set
optimization level as O1,O2,O3 and Os.
If I have to recompile and rerun the tests. What version of llvm is
suggested. It would be better if anyone could provide the patch on this
bug.
Regards
Muhui...
2016 Feb 09
2
Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)
...ze how different flags affect ASan / SoftBoundCETS
>>> / gcc-mpx / icc-mpx.
>>> I will also use a set of microbenchmarks/benchmarks (e.g., RIPE) to
>>> test the protection provided.
>>>
>>> > SPEC2006 is well know so it could be useful. Especially 483.xalancbmk
>>> > Besides, maybe you could take something that is not strictly a
>>> benchmark.
>>> > E.g. take pdfium_test (https://pdfium.googlesource.com/pdfium/) and
>>> feed
>>> > several large pdf files to it.
>>>
>>> Thanks, I will...
2012 Sep 29
7
[LLVMdev] LLVM's Pre-allocation Scheduler Tested against a Branch-and-Bound Scheduler
...lbench 21.2 20.2 4.95%
401.bzip2 13.9 13.6 2.21%
403.gcc 19.5 19.8 -1.52%
429.mcf 20.5 20.5 0.00%
445.gobmk 18.6 18.6 0.00%
456.hmmer 11.1 11.1 0.00%
458.sjeng 19.3 19.3 0.00%
462.libquantum 39.5 39.5 0.00%
464.h264ref 28.5 28.5 0.00%
471.omnetpp 15.6 15.6 0.00%
473.astar 13 13 0.00%
483.xalancbmk 21.9 21.9 0.00%
GEOMEAN 19.0929865 19.00588287 0.46%
410.bwaves 15.2 15.2 0.00%
416.gamess CE CE #VALUE!
433.milc 19 18.6 2.15%
434.zeusmp 14.2 14.2 0.00%
435.gromacs 11.6 11.3 2.65%
436.cactusADM 8.31 7.89 5.32%
437.leslie3d 11 11 0.00%
444.namd 16 16 0.00%
447.dealII 25...
2012 Apr 09
0
[LLVMdev] Implementing minimal debug info (-g1?) for Clang
....
> (See this patch at http://old.nabble.com/-patch--Add-new--gmlt-option-for-min.-debug-info-with-line-tables-(issue4440072)-td31482851.html
> or http://codereview.appspot.com/4440072). This patch is used in Google for about 2 years already.
>
> I get the following binary sizes of 483.xalancbmk benchmark from SPEC 2006 (clang from trunk vs. gcc 4.6.x with Google patches):
> 11026073 Xalan_base.clang_O0
> 45882529 Xalan_base.clang_O0_g
> 11079688 Xalan_base.gcc_O0
> 16437776 Xalan_base.gcc_O0_gmlt
> 54221056 Xalan_base.gcc_O0_g
>
> WDYT of implementing similar option...
2016 Oct 27
2
(RFC) Encoding code duplication factor in discriminator
...ilc 23.59%
444.namd 6.25%
447.dealII 8.43%
450.soplex 2.41%
453.povray 5.40%
470.lbm 0.00%
482.sphinx3 7.10%
400.perlbench 2.77%
401.bzip2 9.62%
403.gcc 2.67%
429.mcf 9.54%
445.gobmk 7.40%
456.hmmer 9.79%
458.sjeng 9.98%
462.libquantum 10.90%
464.h264ref 30.21%
471.omnetpp 0.52%
473.astar 5.67%
483.xalancbmk 1.46%
mean 7.86%
Dehao
On Thu, Oct 27, 2016 at 11:55 AM, Xinliang David Li <davidxl at google.com>
wrote:
> Do you have an estimate of the debug_line size increase? I guess it will
> be small.
>
> David
>
> On Thu, Oct 27, 2016 at 11:39 AM, Dehao Chen <dehao at google.c...
2018 Nov 03
2
llvm bug 36466 fix
...are.
>>
>
> Sorry, I meant the hardware you're using to compile LLVM - you mentioned
> it took you a long time to rebuild it so it would be hard for you to
> write/experiment on tests.
>
>
>> I am using clang to analysis the ARM binaries. The binary is
>> 483.xalancbmk in CPU SPEC2006. When I use the optimization O0, no crash
>> will occur. The crash occurs when I set optimization level as O1,O2,O3 and
>> Os.
>>
>
> Could you try reducing this test further? Taking the code/compile commands
> and try to reduce the remove anything in the...
2013 Jun 20
0
[LLVMdev] Proposal: type uniquing of debug info for LTO
...------------
> Problem:
> A single class can be used in multiple source files and the DI (Debug Info) class is included in multiple bc files. The duplication of
> class definitions causes blow-up in # of MDNodes, # of DIEs, leading to large memory requirement.
>
> As an example, SPEC xalancbmk requires 7GB of memory when compiled with -flto -g.
> With a preliminary implementation of type uniquing, the memory usage will be down to 2GB.
>
> In order to unique types, we have to break cycles in the MDNodes.
>
> A simple struct definition
> struct Base {
> int a;
> };...
2012 Sep 29
0
[LLVMdev] LLVM's Pre-allocation Scheduler Tested against a Branch-and-Bound Scheduler
...5 19.8 -1.52%
> 429.mcf 20.5 20.5 0.00%
> 445.gobmk 18.6 18.6 0.00%
> 456.hmmer 11.1 11.1 0.00%
> 458.sjeng 19.3 19.3 0.00%
> 462.libquantum 39.5 39.5 0.00%
> 464.h264ref 28.5 28.5 0.00%
> 471.omnetpp 15.6 15.6 0.00%
> 473.astar 13 13 0.00%
> 483.xalancbmk 21.9 21.9 0.00%
> GEOMEAN 19.0929865 19.00588287 0.46%
> 410.bwaves 15.2 15.2 0.00%
> 416.gamess CE CE #VALUE!
> 433.milc 19 18.6 2.15%
> 434.zeusmp 14.2 14.2 0.00%
> 435.gromacs 11.6 11.3 2.65%
> 436.cactusADM 8.31 7.89 5.32%
> 437.leslie3d 11 11...
2018 Nov 03
2
llvm bug 36466 fix
...terInfo.cpp:87: int
llvm::MCRegisterInfo::getLLVMRegNum(unsigned int, bool) const: Assertion `I
!= M+Size && I->FromReg == RegNum && "Invalid RegNum"' failed.
Stack dump:
0. Program arguments: /home/linux/llvm-7/llvm/build/bin/llvm-dwarfdump
-debug-info C++/483.xalancbmk.O1
#0 0x000000000093ab37 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/linux/llvm-7/llvm/lib/Support/Unix/Signals.inc:490:0
#1 0x000000000093abca PrintStackTraceSignalHandler(void*)
/home/linux/llvm-7/llvm/lib/Support/Unix/Signals.inc:554:0
#2 0x00000000009388d8 llvm::sys::RunSignalHandl...