similar to: [LLVMdev] exception handling broken on x86-64?

On Feb 9, 2008, at 11:20 AM, Anton Korobeynikov wrote: > Dale, > >> Works for me on x86-64 Darwin, fwiw. > That looks pretty strange. Ok, it can work for small testcases, but > will > surely fail when you try to use for something more real. Currently > it at > least lacks information about frame moves. So, every invoke, which > needs > to restore

Where we are on the subject... Are we sure EH is done for x86? These two tests have never worked on Mac OS X / x86: SPEC/CINT2006/471.omnetpp Shootout-C++/except Evan On Feb 9, 2008, at 2:57 PM, Dale Johannesen wrote: > > On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >>> After comparing the generated assembler code with native gcc code I >>> think the generated

On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >> After comparing the generated assembler code with native gcc code I >> think the generated code is fine, just the exception handler info in >> the non-code sections is broken/missing. > It seems, that EH dwarf information emission is disabled in > X86TargetAsmInfo.cpp. Remove the is64Bit() condition near >

Hello, Thomas > > I'd suggest to start with filling necessary bits in the > > X86RegisterInfo.cpp. This includes frame moves information and > > description of stack layout. > I looked at X86RegisterInfo.cpp, but I think that it already supports > x86-64. At least there were no obvious places were the code would only > work for 32bit mode. Right. See my last e-mail

Hello Evan and Dale, > Shootout-C++/except works for me. Anton suggests there may be an > issue with the unwinding libraries and he may be right, I'll look at > it with you tomorrow. Yes. Please be sure, that you're linking with system libgcc.{so,dylib}, not with llvm-compiled one. -- WBR, Anton Korobeynikov

Perhaps you noticed that LLVM gained a new optimizing register allocator yesterday (r130568). Linear scan is going away, and RAGreedy is the new default for optimizing builds. Hopefully, you noticed because your binaries were suddenly 2% smaller and 10% faster*. Some noticed because LLVM started crashing or miscompiling their code. Greedy replaces a fairly big chunk of the code generator, so

On Jan 30, 2008, at 9:12 PM, Apache wrote: > http://llvm.org/nightlytest/test.php?machine=231&night=4754 > Name: il0102a-dhcp80.apple.com > Nickname: OldGrawp-O0-PIC > Buildstatus: OK > > New Test Passes: > test/CFrontend/2008-01-28-PragmaMark.c [DEJAGNU] > > > New Test Failures: > Benchmarks/Shootout-C++/except [LLC compile, ] >

Did anything ever come of the work on exception handling for x86_64? I'm having problems with exceptions on linux x86_64. Today, on x86_64 with a recently updated working copy of llvm, I tried calling a JITted function that calls an external function that throws: thrower.cpp: (which gets compiled into a dynamic library) extern "C" void throwexception() { throw 5; } My

It's me. Our ISD::LABEL implementation has issues... Evan On Jan 30, 2008, at 9:34 PM, Dale Johannesen wrote: > > On Jan 30, 2008, at 9:12 PM, Apache wrote: > >> http://llvm.org/nightlytest/test.php?machine=231&night=4754 >> Name: il0102a-dhcp80.apple.com >> Nickname: OldGrawp-O0-PIC >> Buildstatus: OK >> >> New Test Passes: >>

Hello, I have some problems running some tools of java in CentOS. Anyone know where is the problem for this? > [jv at localhost ~]$ java org.apache.xalan.xslt.Process > Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.xalan.xslt.Process > at gnu.java.lang.MainThread.run(libgcj.so.7rh) > Caused by: java.lang.ClassNotFoundException:

Hi Dale, > > this is the bit I don't understand. Why does it go > > into a loop? How can the unwinder possibly know that > > the original code did not have a catch-all, since we > > tell it which catches there are and we say: there is > > a catch-all! > > The unwinder works by doing a stack crawl to find a handler. Since > we're telling it

Hello; I was able to build and install llvm(3.0) under Ubuntu 11.10 (using the ./configure script found under llvm source, and then make and make install). While configuring, I gave --prefix as a directory where I would like llvm to be installed. I did not give --with-llvmgccdir and the --enable-optimized argument to configure. Because 3.0 doesn't come with llvmgcc source/binaries and I

So I couldn't get exceptions to work on PPC darwin. After much digging and confusion, there seem to be two separate issues. The gcc testsuite is running the version of the unwinding code that was built with the local (llvm-)gcc, which doesn't work because nobody has implemented builtin_return_address for that target. So that's one problem. More seriously, the version of the

This nightly tester is now using an llvm-g++ that produces the new ODR linkage types. This means that many more functions are being considered by the inter-procedural optimization passes (for example, "linkonce" functions defined in a header). The result seems to be pretty huge swings (both good and bad) in the C++ tests in the testsuite, see below. Note that this tester is often

Hi Dale, > - Why was C++ claiming that every selector has a catch-all handler? this is easy: because the semantics of invoke require it. Yes, really. If unwinding reaches an invoke then control is required to jump to the unwind basic block. At first I thought this probably wouldn't matter - that it would be OK to not jump to the landing pad if the exception was not being caught by it -

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".

Hi Tanya, Here's my second attempt on Fedora Core 5. The changes this time are: 1. Using GCC 4.0.3 as the compiler 2. Building everything from source (no pre-built binaries used) BUILD LLVM WITH GCC 4.0.3 * No issues, just the usual warnings. BUILD LLVM-GCC WITH GCC 4.0.3 * No issues RUN LLVM-TEST WITH GCC 4.0.3 * The following failures were encountered. Some of them are

Tanya, Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5) HIGH LEVEL COMMENTS * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't that be llvm-1.9? * LLVM was built in Release mode in all cases * I don't think this is ready for release. In particular the llvm-gcc4 binary seg faults on FC 5 for most of llvm-test programs. *

On 2/7/2017 20:02, Kostya Serebryany wrote: > ... > > My understanding is that BNDCU is the cheapest possible instruction, > just like XOR or ADD, > so the overhead should be relatively small. > Still my guesstimate would be >= 5% since stores are very numerous. > And such overhead will be on top of whatever overhead SafeStack has. > Do you have any measurements to

Hi all i took a look into LLVM benchmarks from nightly tester and ran Shootout tests on my own. Below go just few outlines. 1. results on my AMD AthlonXP and Xeon used by LLVM team are different sometime. In particular, both Shootout and Shootout-C++ show great speed up with LLVM (in comparison to GCC) on ackerman test on my AthlonXP. But here: