similar to: exception handling optimization

Yes I'm looking for either community approval or reasons I might be barking up the wrong tree :) Maybe someone else explored this idea and there's some big roadblock. I would like to contribute myself, and there may be others like Emil who want to help. I just wanted to let you all know what I want to optimize since I've never contributed to clang before (sorry I don't have

Hello again LLVM devs, Here's the request for comments on the throw2goto exception optimization project. (This is my first one, I don't know who gives out the official numbers for proposals :)) Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200520/6b236ffd/attachment-0001.html>

Hello friends, A couple years back I’ve started a M68K codegen port of LLVM, and then suspended it for the lack of free time. Now I finally got some time and willing to continue working on it. To keep up with LLVM changes I'd like to merge it upstream. There is already patch for it: https://reviews.llvm.org/D50314 <https://reviews.llvm.org/D50314>, but then I was reminded that adding

Hi Anton, Thanks for the tip. I’ve moved some common code from the patch: https://reviews.llvm.org/D50784 <https://reviews.llvm.org/D50784> https://reviews.llvm.org/D50856 <https://reviews.llvm.org/D50856> https://reviews.llvm.org/D50858 <https://reviews.llvm.org/D50858> but the backend itself is still quite large. Anything more I can do to simplify reviewing? > On 15 Aug

Anton Korobeynikov wrote: > Hello, > >> #1 0x00000033fc810c66 in _Unwind_RaiseException () from >> #/lib64/libgcc_s.so.1 >> #2 0x00000033fd4c3dbd in __cxa_throw () from /usr/lib64/libstdc++.so.6 > What's your native gcc version? > gcc-4.3.0-8.x86_64

Anton Korobeynikov wrote: > Hi, Neal > >> gcc-4.3.0-8.x86_64 > This is known problem: http://llvm.org/bugs/show_bug.cgi?id=2998 > Thank you. Is there a workaround?

Compiled boost-1.37.0 using llvm-2.4 (OK). Attempting to use it I get: Program received signal SIGSEGV, Segmentation fault. 0xfffffffffd4c3720 in ?? () (gdb) where #0 0xfffffffffd4c3720 in ?? () #1 0x00000033fc810c66 in _Unwind_RaiseException () from /lib64/libgcc_s.so.1 #2 0x00000033fd4c3dbd in __cxa_throw () from /usr/lib64/libstdc++.so.6 #3 0x0000000000636df3 in

On 02/04/2013 09:32 PM, Anton Korobeynikov wrote: >> am I wrong or the ARM c++ exceptions handling does not work? > Yes, it's still work-in-progress option disabled by default. You might > want to give it a try via special cmdline line -mllvm > -arm-enable-ehabi Ohhh I see, thanks for the input! > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics

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

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 call-clobbered registers during unwinding will be broken. Does Shootout-C++/except work for you? And stuff from llvm

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

> am I wrong or the ARM c++ exceptions handling does not work? Yes, it's still work-in-progress option disabled by default. You might want to give it a try via special cmdline line -mllvm -arm-enable-ehabi -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

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, > #1 0x00000033fc810c66 in _Unwind_RaiseException () from /lib64/libgcc_s.so.1 > #2 0x00000033fd4c3dbd in __cxa_throw () from /usr/lib64/libstdc++.so.6 What's your native gcc version? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi, Neal > gcc-4.3.0-8.x86_64 This is known problem: http://llvm.org/bugs/show_bug.cgi?id=2998 -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello, Neal > Thank you. Is there a workaround? Well, I suppose, that one of the following might work: 1. downgrade gcc 2. link everything statically -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello David, I believe Johannes already answered your questions, but just to clarify the things fully: yes, we are going to submit an application to participate in GSoC this year as usual. I will take care of necessary paperwork and stuff. Currently we're collecting the list of summer projects here and there. It's perfectly fine to have the lists from sub-projects to be posted on their

On Jun 3, 2009, at 18:50, Eli Friedman wrote: > On Wed, Jun 3, 2009 at 2:20 PM, Joe Ranieri<joe at alacatialabs.com> > wrote: >> Has any progress been made on structured exception handling on >> Windows? I saw a post by Duncan Sands back in September 2008, but >> haven't seen anything since. I'm trying to generate code to run on >> Windows, but would

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