similar to: [LLVMdev] About clock and wait instruction

Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] About clock and wait instruction"

2003 Dec 18
0
[LLVMdev] About clock and wait instruction
On Fri, 19 Dec 2003, Yueqiang wrote: > In high level languge there are usually have time and sync instruction, > to handle async and sync operation. > I want to know how LLVM take an count of these. I'm not sure exactly what 'time' and 'sync' operations you're talking about, or what languages support them. However, LLVM is designed to make it trivial to
2003 Dec 19
2
[LLVMdev] About clock and wait instruction
Chris Lattner wrote: > On Fri, 19 Dec 2003, Yueqiang wrote: > > >>In high level languge there are usually have time and sync instruction, >>to handle async and sync operation. >>I want to know how LLVM take an count of these. > > > I'm not sure exactly what 'time' and 'sync' operations you're talking > about, or what languages
2003 Dec 18
0
[LLVMdev] About clock and wait instruction
On Fri, 19 Dec 2003, Yueqiang wrote: > hi, > > like in C/C++ language there are time/date and istream::sync function. If an operation can be written in C/C++ or some other high-level language, then it should be. It can be directly compiled to LLVM bytecode. In our case you can llvm-dis llvm-gcc/lib/libstdc++.so to see what we compile it into. > also in RISC system Data/Inst Cache
2011 Oct 04
3
[LLVMdev] setjmp - longjmp
Hi, I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable is inserted, which is fine. The problem is that in the backend before calling longjmp, some register was spilled to a stack location which is live across the jmp. I mean, it will be live after jumping. The stack location was initialized before the call to setjmp, and is used afterwards. Is there any bug in handling
2015 Apr 28
2
[LLVMdev] MCJIT longjmp failure on Win64 - was Invalid or unaligned stack exception on Windows
On 28 April 2015 at 00:30, Reid Kleckner <rnk at google.com> wrote: > I think Paweł identified the problem. The frames on the stack between the > setjmp and longjmp must have valid unwind information, which is described > here: > https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396 > > In particular, it has this line about JITed code: >
2011 Oct 04
2
[LLVMdev] setjmp - longjmp
On Oct 4, 2011, at 3:53 PM, Eli Friedman wrote: > On Tue, Oct 4, 2011 at 3:10 PM, Khaled ElWazeer > <khalid.alwazeer at gmail.com> wrote: >> Hi, >> >> I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable >> is inserted, which is fine. The problem is that in the backend before >> calling longjmp, some register was spilled to a
2011 Feb 16
2
fwd: fix up ARM assembly to use 'bx lr' in place of 'mov pc, lr'.
hello vorlon, got notified of your patch, will apply next days upstream unless some critiques are voiced on ml. thanks. -- maks ----- Forwarded message from Steve Langasek <steve.langasek at canonical.com> ----- Date: Wed, 16 Feb 2011 22:05:42 -0000 From: Steve Langasek <steve.langasek at canonical.com> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses
2014 May 27
2
[LLVMdev] Do the LLVM SJLJ intrinsics interact with C++ exception handling and execute C++ cleanup actions?
Do the LLVM Setjmp/Longjmp intrinsics interact with C++ exception handling and execute C++ cleanup actions? I compiled a small example using setjmp/longjmp using clang and they did not execute C++ cleanup actions and calling longjmp bypassed calling destructors on objects that were allocated between the call to setjmp and longjmp. I’m wondering if the LLVM intrinsics behave differently from
2013 May 08
1
[LLVMdev] Clarifying the state of setjmp/longjmp support in LLVM and Clang
I'm trying to make sense in the support for setjmp/longjmp in Clang and LLVM, with only partial success. I'll try to summarize my findings in the hope that someone can shed some light on why things are the way they are and what I'm missing. Clang. Clang recognizes two forms of setjmp (all I say here applies to longjmp similarly): * __builtin_setjmp: gets lowered to calling the
2005 Nov 21
1
[LLVMdev] setjmp/longjmp interoperable between llvm and gcc?
Hi, I would like to build an x86 executable consisting of a number of subsystems (mostly legacy C code). One subsystem will be compiled to native code using llvm. It calls, and is called by, the other subsystems, many of which have to be compiled using gcc because they use small amounts of inline assembly. All of the subsystems catch and throw errors to one another using setjmp/longjmp. When
2012 Oct 02
2
[PATCH] fix ARM longjmp with zero 'val'.
[klibc] [PATCH] fix ARM longjmp with zero 'val'. We need to set the condition codes on the ARM. The previous version was using a left over condition code from the caller. Also, use conditional execution to eliminate branch and reduce size. Signed-off-by: Bill Pringlemeir <bpringle at sympatico.ca> diff --git a/usr/klibc/arch/arm/setjmp.S b/usr/klibc/arch/arm/setjmp.S index
2011 Apr 13
4
[LLVMdev] built-in longjmp and setjmp
On Apr 12, 2011, at 3:15 PM, Jim Grosbach wrote: > If you want an automated method, then using the source code re-writer interfaces in clang is probably a reasonable starting place. Just modifying the source code manually is probably easier, though, to be honest. > > As a moderate caveat to all of this, there are some bits of code out there that use these builtins that are very tightly
2011 Apr 13
0
[LLVMdev] built-in longjmp and setjmp
It seems straightforward to implement, if it just needs to be functionally correct. I have another question about setjmp/longjmp. When the following program is compiled and run with argument 10 (./a.out 10), should it print 10 or 23? I am asking this question because it prints 23 when compiled with gcc and prints 10 when compiled with clang. If it is supposed to return 23, it seems to me that
2007 Aug 24
2
[LLVMdev] llvm-gcc4 and setjmp
Hi Anton, > > I would expect llvm-gcc to use LLVM's setjmp/longjmp intrinsics and > > then to run the LowerSetJmp pass to turn the intrinsic calls into uses > > of invoke and unwind. At that point, the control flow is explicit, > > isn't it? > Unfortunately, no. You can call setjmp/longjmp on the same jump buffer > multiple times. So, in general it's not
2011 Oct 04
0
[LLVMdev] setjmp - longjmp
On Tue, Oct 4, 2011 at 3:10 PM, Khaled ElWazeer <khalid.alwazeer at gmail.com> wrote: > Hi, > > I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable > is inserted, which is fine. The problem is that in the backend before > calling longjmp, some register was spilled to a stack location which is live > across the jmp. I mean, it will be live after
2020 Mar 27
2
Efficient Green Thread Context-Switching
The first time you said “setjmp/longjmp intrinsics” I thought it was a typo, and that you were talking about the C standard library functions. If you’re actually talking about LLVM intrinsics, are they documented? I don’t see any intrinsics with those names in the language reference (https://llvm.org/docs/LangRef.html <https://llvm.org/docs/LangRef.html>). > On Mar 27, 2020, at 3:30 PM,
2011 Oct 05
0
[LLVMdev] setjmp - longjmp
That code should do it, but I realized you only detect setjmp functions by name. My code is calling "__sigsetjmp" not "segsetjmp". You only support these functions: static const char *ReturnsTwiceFns[] = { "_setjmp", "setjmp", "sigsetjmp", "setjmp_syscall", "savectx", "qsetjmp",
2009 Feb 26
2
[LLVMdev] Question LowerSetJmp
Hi In llvm src the file llvm/lib/Transforms/IPO/LowerSetJmp.cpp, it seems for sjlj-eh ? but this pass has no effect about c++ sjlj-eh. this pass is for future extend? zhangzw
2017 Nov 04
3
returns_twice / noreturn
On 11/03/2017 07:57 PM, Yichao Yu wrote: > On Fri, Nov 3, 2017 at 8:54 PM, Alexandre Isoard via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: >>> >>> Hello, >>> >>> I am not sure about the
2016 Sep 16
2
setjmp/longjmp and volatile stores, but non-volatile loads
Hi, In our (non-C) compiler we use setjmp/longjmp to implement exception handling. For the initial implementation LLVM backend, I'm keeping that model. In order to ensure that changes performed in a try/setjmp==0 block survive the longjmp, the changes must be done via volatile operations. Given that volatility is a property of individual load/store instructions rather than of memory slots in