search for: istore

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

...with great names for these instructions, but: - 'iload' is to 'load' as 'invoke' is to 'call'. That is, the instruction is a terminator and has normal and unwind destinations. e.g. %v = iload i8* %ptr to label %try.cont unwind label %lpad - Similarly, 'istore' is to 'store' as 'invoke' is to 'call'. istore i8 %v, i8* %ptr to label %try.cont unwind label %lpad These instructions always have 'nullcheck' semantics, plus: - If the instruction traps and the program has installed a signal handler for the trap whic...

...- 'iload' is to 'load' as 'invoke' is to 'call'. That is, the instruction is > > a terminator and has normal and unwind destinations. e.g. > > > > %v = iload i8* %ptr to label %try.cont unwind label %lpad > > > > - Similarly, 'istore' is to 'store' as 'invoke' is to 'call'. > > > > istore i8 %v, i8* %ptr to label %try.cont unwind label %lpad > > > > These instructions always have 'nullcheck' semantics, plus: > > > > - If the instruction traps and the p...

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.

...low within the loop to aid loop analysis and other optimizations. So we still want the front end to emit the intrinsic, we just may eventually want it lowered earlier than CGP. I don't think this issue has any bearing on the intrinsic's LangRef spec. There was some comparison made to iload/istore, which I don't follow: - subsuming loads and stores into another instruction is really scary considering how much logic we have for analyzing the side effects of memory access. - there is no benefit to IR optimization to the iload/istore intruction. - it is easy to detect null checked load/...

...insic anyway. Heh, I wouldn't call it asm.js.  asm.js adopted something that was already a de-facto idiom. But yes - most people want to be told if the denominator was zero but want INT_MIN/-1 to flow through gracefully and have defined behavior. There's also the discussion of iload and istore, where the consensus was that we'd rather have explicit null checks and branches. Lol.  Since you brought that up, I figure I might as well throw this out: probably some VMs will want a guaranteed trap on divide-by-zero as a free way of throwing the exception.  I actually think that the safediv...

...r optimizations. So we still want the front end > > to emit the intrinsic, we just may eventually want it lowered earlier > > than CGP. I don't think this issue has any bearing on the intrinsic's > > LangRef spec. > > > > There was some comparison made to iload/istore, which I don't > > follow: > > - subsuming loads and stores into another instruction is really scary > > considering how much logic we have for analyzing the side effects of > > memory access. > > - there is no benefit to IR optimization to the iload/istore intru...

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/

...outline the body of the __try block > and mark it noinline, which is what I propose to do initially. > > Long term, we could lower all potentially trapping operations to > intrinsics that we 'invoke' at the IR level. See also Peter Collingbourne's > proposal for iload and istore instructions here ( > http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/071732.html). > > With the outlining approach, in addition to noinline, we need to invent > another function attribute to prevent functionattrs from inferring nounwind > and readonly, or the optimizers will d...

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:

...#39;s life scope, the dtor must be invoked the same way as C++ Synchronous Exception during unwinding process. **** Design and Implementation: **** A natural way to achieve the rules above in LLVM today is to allow an EH edge added on memory/computation instruction (previous iload/istore idea) so that exception path is modeled in Flow graph preciously. However, tracking every single memory instruction and potential faulty instruction can create many Invokes, complicate flow graph and possibly result in negative performance impact for downstream optimization and...

...e volatile. Finally I would not say it's at the cost of terrible performance because: (1) Again, in really world code, it's very small amount of code are directly inside a _try, and they are mostly not performance critical. (2) If the HW exception flow is perfectly modeled with iload/istore or with pointer-test explicit flow model, likely optimizations will be severely hindered. The result code will be probably not much better than volatile code. Thanks, --Ten From: Eli Friedman <efriedma at quicinc.com<mailto:efriedma at quicinc.com>> Sent: Wednesday, April 1, 2020 5:...

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

...: 44689 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080612/58edfb17/attachment.bin> -------------- next part -------------- 630: iload local_4_113 = 0 632: iload local_5_114 = 57 local_4_113 = 0 634: if_icmplt 132: aload_3 133: iload 135: caload 136: istore 138: iload 140: sipush 143: if_icmpge 146: iload 148: iload 150: if_icmplt 185: aload 187: iload 189: iinc 192: iload 194: i2b 195: bastore 196: iinc 199: goto 630: iload local_4_419 = 1 632: iload local_5_420 = 261095424 local_4_419 = 1 -------------- next part -------------- 2646: li 3,...

...to emit the intrinsic, we just may eventually want it lowered >> earlier >> > than CGP. I don't think this issue has any bearing on the >> intrinsic's >> > LangRef spec. >> > >> > There was some comparison made to iload/istore, which I don't >> > follow: >> > - subsuming loads and stores into another instruction is really >> scary >> > considering how much logic we have for analyzing the side >> effects of >> > memory access. >> >...

...#39;s life scope, the dtor must be invoked the same way as C++ Synchronous Exception during unwinding process. **** Design and Implementation: **** A natural way to achieve the rules above in LLVM today is to allow an EH edge added on memory/computation instruction (previous iload/istore idea) so that exception path is modeled in Flow graph preciously. However, tracking every single memory instruction and potential faulty instruction can create many Invokes, complicate flow graph and possibly result in negative performance impact for downstream optimization and...

...work around this is to outline the body of the __try block and mark it noinline, which is what I propose to do initially. Long term, we could lower all potentially trapping operations to intrinsics that we 'invoke' at the IR level. See also Peter Collingbourne's proposal for iload and istore instructions here (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/071732.html). With the outlining approach, in addition to noinline, we need to invent another function attribute to prevent functionattrs from inferring nounwind and readonly, or the optimizers will delete the invoke unwind e...

...in the middle of an object's life scope, the dtor must be invoked the same way as C++ Synchronous Exception during unwinding process. Design and Implementation: A natural way to achieve the rules above in LLVM today is to allow an EH edge added on memory/computation instruction (previous iload/istore idea) so that exception path is modeled in Flow graph preciously. However, tracking every single memory instruction and potential faulty instruction can create many Invokes, complicate flow graph and possibly result in negative performance impact for downstream optimization and code generation. Mak...