similar to: [LLVMdev] UpgradeExceptionHandling

Hi, I'm trying to use exception control by LLVM. In the demo page, I got : declare i8* @llvm.eh.exception() nounwind But, when a try to emit the code by llvm engine, the name is generate with the sufix .132 ( llvm.eh.exception.132 ) and the Function::getIntrinsicID abort the program. It was so : Intrinsic::getDeclaration(llvm_module,Intrinsic::memset,&Tys,1); Now, it's

Hi. I am a little unclear about the ARM JIT support status. Is it working as of LLVM 3.1? If not, is it on the roadmap for LLVM 3.2? I am not currently interested in NEON support so if thats unimplemented, thats fine. thanks, Rahul

2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Yes. The issue here, as you pointed out, is that your personality function > is not called at all. > Even if you did nothing in the personality function, associated with the > setup caused by > llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be > called. > Your results are acting like either

Hi all, Is it too soon to start porting EH code to the new C++ API? Are there sample implementations? llvm.org/demo still uses the old EH gizmos. should we wait for 3.0 release? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/3bc09ea9/attachment.html>

The only reference that I found so far here: http://llvm.org/devmtg/2011-09-16/EuroLLVM2011-LLVMplusARM.pdf The presenter states that the ARM JIT support is broken. But this is about 10 months old. Is the ARM JIT support still broken? Am I not looking at the right places in the documentation? Help will be appreciated. thanks, Rahul On Mon, Jul 30, 2012 at 4:53 AM, Rahul Garg <rahulgarg44 at

here are the cpp file: $ cat -n eh1.catch.cpp 1 #include <iostream> 2 3 int main() 4 { 5 try { 6 throw 78; 7 } 8 catch (int){ 9 10 std::cout << "at catch\n"; 11 12 } 13 } LLVM-IR: $ llvm-g++ -S -emit-llvm eh1.catch.cpp -o eh1.catch.ll ... 46 define i32 @main() {

Hi Rahul, I believe that ARM support is working in the MCJIT engine (as of llvm 3.1). If it wasn't working in the legacy JIT engine 10 months ago then it probably still isn't. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rahul Garg Sent: Tuesday, July 31, 2012 1:13 PM To: llvmdev at cs.uiuc.edu Subject: Re:

>> The days of the old .ll parser are long gone, but is it too late to >> change? In case it is not, the attached patches implement just that >> :-) > I'm afraid you need to provide syntax autoupgrade until 4.0 Why, we moved to doing autoupgrade via bitcode quiet some time ago. There were quiet a few format changes to the .ll in the process. Cheers, Rafael

On Fri, Nov 22, 2013 at 10:14 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Fri, Nov 22, 2013 at 9:54 AM, Eric Christopher <echristo at gmail.com> > wrote: >> >> On Fri, Nov 22, 2013 at 9:08 AM, David Blaikie <dblaikie at gmail.com> wrote: >> > >> > >> > >> > On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren

On Thu, Nov 21, 2013 at 12:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 11:45 AM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Thu, Nov 21, 2013 at 11:26 AM, David Blaikie <dblaikie at gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Nov 21, 2013 at

I think the general backward-compatibility story has been kind of vague for a while. There was some talk about it at the time of the version-numbering change, but I don't remember if it came to any kind of solid conclusion. I think the handling of the old X86 intrinsics would want to follow the general compatibility policy, assuming we can all agree on one. There shouldn't be a special

On Fri, Nov 22, 2013 at 9:08 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >> >> >> >> On Thu, Nov 21, 2013 at 12:01 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >>> >>> >>> >>> >>> On Thu,

On Fri, Nov 22, 2013 at 9:54 AM, Eric Christopher <echristo at gmail.com>wrote: > On Fri, Nov 22, 2013 at 9:08 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren <manman.ren at gmail.com> > wrote: > >> > >> > >> > >> > >> On Thu, Nov 21, 2013 at

Hi Eli, What exactly do mean by an AutoUpgrade patch? I don't see how this could cause any issues with backward compatibility. People currently using these intrinsics need a bitcast of the result to avoid an assert, and with the patch applied the bitcast is no longer necessary. Cheers, Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

Is there a reason why? IE is it hard to maintain, slow, or are you just worried it will break? or something else? (I'm not opposed in any way, literally just want to understand the motivation) On Wed, Sep 20, 2017 at 12:20 PM, Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics > that have

On Mon, Nov 18, 2013 at 10:35 AM, Eric Christopher <echristo at gmail.com>wrote: > >> At a minimum, it seems like we need a version number in the debug info > >> metadata so we can detect this situation and avoid crashing. > > > > > > Or to put it in the terms of the IR: we need to autoupgrade the debug > info > > metadata just like we do

Yes. The issue here, as you pointed out, is that your personality function is not called at all. Even if you did nothing in the personality function, associated with the setup caused by llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be called. Your results are acting like either dwarf exception header info is not emitted (llvm::DwarfExceptionHandling = true; not executed

On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 12:01 PM, David Blaikie <dblaikie at gmail.com>wrote: > >> >> >> >> On Thu, Nov 21, 2013 at 11:45 AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Nov 21, 2013 at

We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics that have been replaced with native IR over the years. Has enough time and/or versions passed that we can begin phasing out some of this code? As I'm writing these we don't seem to have tests for a lot of the older upgrades. We've done better at this in the last few years. 3.1 added upgrade for:

FYI, The CRC64 intrinsics were renamed to CRC32 since there is no such thing. See below for details. Chad On May 26, 2011, at 4:13 PM, Chad Rosier wrote: > Author: mcrosier > Date: Thu May 26 18:13:19 2011 > New Revision: 132163 > > URL: http://llvm.org/viewvc/llvm-project?rev=132163&view=rev > Log: > Renamed llvm.x86.sse42.crc32 intrinsics; crc64 doesn't exist.