search for: istores

Hi all, I'm trying to figure out a weird bug I'm seeing. I'm hoping it's something simple in my IR but I can't see anything wrong so I'm hoping someone here can see something. I'm using LLVM to compile Java bytecode into native functions. My code keeps track of the Java local variables in an array of llvm::Value pointers which get phi'd up at various points. The

Hi, I wanted to propose an IR extension that would allow us to support zero-cost exception handling for non-call operations that may trap. I wanted to start with loads and stores through a null pointer, and later we might extend this to div/rem/mod zero. This feature is obviously useful for implementing languages such as Java and Go which deterministically translate such operations into

...M’s optimizer and instruction selection. But you’re not removing the control flow, so this technique does not apply. Null checks should actually be exposed in IR so general optimizations can remove redundant checks. My idea for removing redundant checks is to teach the IR optimizer to treat iloads/istores as if they were null checks. Is there any reason why this wouldn't work? > Ideally this would just be a machine code pass that can hoist a load/store above a branch and nuke the compare. However, I can see how it’s easier to relate the compare operand to the address arithmetic at IR level....

Hi there, during peak load on some running domU, I noticed random iSCSI "Reported LUNs data has changed" which forced me to shutdown the respective domU, re-login the target and do a fsck before starting domU again. This occurred on a 16 core machine, having only about 14 domUs running. Spare memory has been occupied by dom0 (about 40G). Each domU has it''s own iSCSI target.

On Apr 25, 2014, at 2:21 PM, Eric Christopher <echristo at gmail.com> wrote: >> In short, I agree with your observations that these intrinsics are not an >> obvious slam-dunk compared to making the explicit control flow, but I think >> that the intrinsics do give enough flexibility on the LLVM side that it >> would be great if front-ends used them rather than rolling

On April 25, 2014 at 1:44:37 PM, Reid Kleckner (rnk at google.com) wrote: Thanks for the writeup! It's very helpful. On Fri, Apr 25, 2014 at 11:49 AM, Filip Pizlo <fpizlo at apple.com> wrote: On April 25, 2014 at 10:48:18 AM, Reid Kleckner (rnk at google.com) wrote: On Fri, Apr 25, 2014 at 10:19 AM, Filip Pizlo <fpizlo at apple.com> wrote: The sdiv operation in LLVM IR only

I am very much in favor of having a div instruction with well defined div-by-zero and overflow behavior. The undefined behavior on certain values for LLVM intrinsics has been a major pain point for us in Julia, because adding the extra branches just kills performance and we know that there is an X86 instruction that just does what we want. Anyway, this was brought up briefly above, but want to

On April 25, 2014 at 10:48:18 AM, Reid Kleckner (rnk at google.com) wrote: On Fri, Apr 25, 2014 at 10:19 AM, Filip Pizlo <fpizlo at apple.com> wrote: The sdiv operation in LLVM IR only makes sense for C and its very direct relatives.  The amount of control flow necessary to represent a safe division for any other language is ghastly.  (a/b) becomes something like (b != 0 ? ((a != INT_MIN ||

On 2008-06-11, at 13:16, Gary Benson wrote: > Duncan Sands wrote: > >> Can you please attach IR which can be compiled to an executable >> (and shows the problem). > > I've been generating functions using a builder and then compiling > them with ExecutionEngine::getPointerToFunction(). Is there some way > I can get compilable IR from that?

Duncan Sands wrote: > Can you please attach IR which can be compiled > to an executable (and shows the problem). I've been generating functions using a builder and then compiling them with ExecutionEngine::getPointerToFunction(). Is there some way I can get compilable IR from that? Cheers, Gary -- http://gbenson.net/

Moving this month old RFC to llvmdev. Not sure why I sent this to cfe-dev in the first place... --- Based on code review discussion from John, he thinks filter expressions should be emitted into the body of the function with the try, rather than being outlined by the frontend. Instead of having the frontend create filter functions, we would use labels in place of typeinfo. The IR would look

Hi Reid, Is this design supposed to be able to cope with asynchronous exceptions? I am having trouble imagining how this would work without adding the ability to associate landing pads with scopes in LLVM IR. Vadim On Tue, Nov 25, 2014 at 5:27 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Nov 25, 2014 at 3:09 PM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote:

Hi, This is a spin-off of previous Windows SEH RFC below. This RFC only focus on supporting HW Exception Handling. A detailed implementation can be seen in here: https://github.com/tentzen/llvm-project/commit/8a2421c274b683051e456cbe12c177e3b934fb5e It passes all MSVC SEH suite (excluding those with “Jumping out of _finally” ( _Local_Unwind)). Thanks, --Ten **** The rules for C code: ****

* When a goto in a _finally occurs, we must "unwind" to the target code, not just "jump" to target label I'm not sure what you're trying to say here. In the Microsoft ABI, goto out of a catch block also calls into the unwinder. We have to run any destructors, and return from the funclet (catchret/cleanupret). * The call inside a _try is an invoke with EH

Reply inline From: Ten Tzen <tentzen at microsoft.com> Sent: Wednesday, April 1, 2020 3:54 PM To: Eli Friedman <efriedma at quicinc.com>; llvm-dev <llvm-dev at lists.llvm.org> Cc: aaron.smith at microsoft.com Subject: [EXT] RE: [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling) ? For goto in finally, why are you

Gordon Henriksen wrote: > On 2008-06-11, at 13:16, Gary Benson wrote: > > Duncan Sands wrote: > > > Can you please attach IR which can be compiled to an executable > > > (and shows the problem). > > > > I've been generating functions using a builder and then compiling > > them with ExecutionEngine::getPointerToFunction(). Is there some > >

As the discussion has progressed and I've spent more time thinking about the topic, I find myself less and less enthused about the current proposal. I'm in full support of having idiomatic ways to express safe division, but I'm starting to doubt that using an intrinsic is the right way at the moment. One case I find myself thinking about is how one would combine profiling

Hi, Eli, Why are you under the impression that threw_exception() will not be called if optimizations are enabled? I don’t know if the -EHa Spec is clearly described in MSFT Webs. At least this proposal has described the rules for both C & C++ code. The very first rule clearly said that “no exception can move in or out of _try region., i.e., no potential faulty instruction can be moved

Hi Reid, I’ve been following your proposal, and I’d be interested in helping out if I can. My main interest right now is in enabling C++ exception handling in clang for native (i.e. not mingw/cygwin) Windows targets (both 32-bit and 64-bit), but if I understand things correctly that will be closely related to your SEH work under the hood. I’m still trying to get up to speed on what is and is

Hi, all, The intend of this thread is to complete the support for Windows SEH. Currently there are two major missing features: Jumping out of a _finally and Hardware exception handling. The document below is my proposed design and implementation to fully support SEH on LLVM. I have completely implemented this design on a branch in repo: