Displaying 20 results from an estimated 24 matches for "jmps".
Did you mean:
jmp
2014 Jul 26
2
[LLVMdev] Finding previous emitted instruction
...ated in the final
JMP <BB1> <--| emitted code.
BB1: <-- the MBB
RET <-- MBBI points here
So the business of finding the previous "real" instruction is starting to
look very complicated. I would need to skip over pseudo-instructions and
somehow to deal with JMPs that will be eliminated later, and who knows what
else...
My question is, am I going about it in the wrong way? Is there an easier
way to achieve what I need?
thanks!
Vadim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-...
2008 Apr 05
0
[LLVMdev] Newbie
...with high execution counts). However, there is still potential for
improvement, one being an efficient implementation of direct block chaining
(in certain cases a block can directly jump to its successor instead of
falling back to the dispatcher, this is currently implemented with calls
instead of jmps, which should be possible to implement with jmps now, after
the recent work on tail call optimizations). Direct block chaining is a
very useful optimization, on the nbench test case enabling direct block
chaining for regular qemu leads to a 100% speed increase. Another promising
improvement would...
2017 Mar 29
3
[inline-asm][asm-goto] Supporting "asm goto" in inline assembly
...(Bug 9295<https://bugs.llvm.org/show_bug.cgi?id=9295>).
As was already proposed, the best way seems to be introducing new IR.
If we're changing the IR, we should probably provide an infrastructure that solves or at least enables future support for things like:
1. MS-style inline asm jmps and goto (Bug 24529<https://bugs.llvm.org/show_bug.cgi?id=24529>)
2. Analyzing symbols defined/references in the inline assembly (Bug 28970<https://bugs.llvm.org/show_bug.cgi?id=28970>), taking into account module/file-scope inline assembly.
3. Provide some information about...
2008 Apr 01
5
[LLVMdev] Newbie
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello,<br>
<br>
We are a research project in joint french-chinese laboratory. We are
considering using<br>
LLVM in our project but we'd like to have some additional info before
we dive in.
2008 Apr 07
2
[LLVMdev] Newbie
...;>
<div><br>
However, there is still potential for improvement, one being an
efficient implementation of direct block chaining (in certain cases a
block can directly jump to its successor instead of falling back to the
dispatcher, this is currently implemented with calls instead of jmps,
which should be possible to implement with jmps now, after the recent
work on tail call optimizations). Direct block chaining is a very
useful optimization, on the nbench test case enabling direct block
chaining for regular qemu leads to a 100% speed increase. Another
promising improvement would...
2012 Mar 06
0
[LLVMdev] Performance degradation when repeatedly exchanging JITted functions
On Tue, Mar 06, 2012 at 04:29:28PM +0100, Clemens Hammacher wrote:
> I think a solution would be to always call a function through it's
> stub, so that there is a single location to update when the function
> is exchanged. This would mean that there is always exactly one level
> of indirection, which is worse for programs that don't exchange
> functions at runtime, but is
2012 Mar 06
2
[LLVMdev] Performance degradation when repeatedly exchanging JITted functions
Surely you need to patch *all* functions, not just the initial?
The point is with the current solution no matter which version of the function another function is linked to, it will hit a sled of JMPs and eventually end up at the newest.
If you only patched the first, that sled wouldn't work. So you'd have to patch all instances. That still shouldn't be too hard.
Cheers,
James
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]...
2012 Mar 06
2
[LLVMdev] Performance degradation when repeatedly exchanging JITted functions
Hi all,
for a research project we need to repeatedly exchange functions in a
program running in the JIT compiler.
We currently do this by calling recompileAndRelinkFunction(), after
changing the body of the function. Of course we synchronize enough to
ensure that the JIT doesn't concurrently compile the function (which
should only happen if lazy compilation is enabled).
Now
2011 Mar 28
2
[LLVMdev] RFC: GSoC Project
...nction which use a fixed
amount of stack space. For the ones which don't, we can assume some
worst-case upper bound. Since the block size is a constant power of two,
this can be done using a bitwise and and an integer comparison. If there
isn't enough space in the current block, the control jmps (does not
call) to a naked function (called setup_new_block)
*** setup_new_block:
setup_new_block will be small naked function emitted into all programs
being compiled with segmented stacks. It does the following:
1. Checks if the current block's next pointer is populated or not.
2. In case...
2017 Mar 30
3
[inline-asm][asm-goto] Supporting "asm goto" in inline assembly
...see high-value reasons to add support for this... If they do...
As was already proposed, the best way seems to be introducing new IR.
If we’re changing the IR, we should probably provide an infrastructure that solves or at least enables future support for things like:
1. MS-style inline asm jmps and goto (Bug 24529<https://bugs.llvm.org/show_bug.cgi?id=24529>)
I *strongly* agree with the 'WONTFIX' resolution here. More than GCC's "asm goto", this feature seems much more harmful to the compiler and much less well motivated.
2. Analyzing symbols defined/ref...
2011 Mar 23
0
[LLVMdev] RFC: GSoC Project
On Wed, Mar 23, 2011 at 03:37:02PM +0530, Sanjoy Das wrote:
> I intend to start with the simplest possible approach - representing the
> stack as a doubly linked list of _block_s, the size of each _block_
> being a power of two. This can later be modified to improve performance
> and accommodate other factors. Blocks will be chained together into a
> doubly linked list structure
2009 Mar 03
5
[LLVMdev] One way to support unwind on x86
...ion), we get the next Instruction Pointer (the
; instruction after the call):
pop eax
; We advance our virtual Instruction Pointer to after
; the first jmp. Here we assume it is a two-byte
; encoded short jmp, but in practice we can support
; both short and long jmps:
inc eax
inc eax
; Then we invoke the local unwind handling. It will
; in turn either unwind another call frame or jump to
; the landing pad:
jmp eax
The pass to raise C++ exceptions to use unwind is another discussion.
The most valuable thing for me is to su...
2007 Apr 18
2
Single PV startup vs multiple PV startup
Hi Rusty,
I had a look over your 011-paravirt-head.S.patch. I'm struggling to
come up with a list of any benefits over having separate entrypoints for
each hypervisor.
Multiple entry pros:
* allows maximum startup flexibility for any given hypervisor
* for Xen at least, it's pretty simple
* the "what hypervisor am I under" question is answered trivially
cons:
2011 Mar 23
5
[LLVMdev] RFC: GSoC Project
Hi All!
I will be applying to the LLVM project for this GSoC, and I wanted some
preliminary sanity check on my project idea.
I intend to implement split (segmented) stacks for LLVM (like we have in
Go, and as being implemented for GCC [1]). A lot of what follows is
lifted from [1]; I will progressively add more details as I get more
familiar with the LLVM codebase.
I intend to start with
2014 Nov 19
5
[LLVMdev] Odd code layout requirements for MCJIT
I'm part of a team working on adding an llvm codegen backend to HHVM
(PHP JIT, http://hhvm.com) using MCJIT. We have a code layout problem
and I'm looking for opinions on good ways to solve it.
The short version is that the memory we emit code into is split into a
few different areas, and we'd like a way to control which area each
BasicBlock ends up in during codegen. I know this
2007 Apr 18
20
[patch 00/20] XEN-paravirt: Xen guest implementation for paravirt_ops interface
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
are:
* domU only
* UP only (most code is SMP-safe, but there's no way to create a new vcpu)
* writable pagetables, with late pinning/early unpinning
(no shadow pagetable support)
* supports both PAE and non-PAE modes
* xen console
* virtual block
2007 Apr 18
20
[patch 00/20] XEN-paravirt: Xen guest implementation for paravirt_ops interface
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
are:
* domU only
* UP only (most code is SMP-safe, but there's no way to create a new vcpu)
* writable pagetables, with late pinning/early unpinning
(no shadow pagetable support)
* supports both PAE and non-PAE modes
* xen console
* virtual block
2007 Apr 18
20
[patch 00/20] XEN-paravirt: Xen guest implementation for paravirt_ops interface
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
are:
* domU only
* UP only (most code is SMP-safe, but there's no way to create a new vcpu)
* writable pagetables, with late pinning/early unpinning
(no shadow pagetable support)
* supports both PAE and non-PAE modes
* xen console
* virtual block
2007 Apr 18
24
[patch 00/24] Xen-paravirt_ops: Xen guest implementation for paravirt_ops interface
Hi Andi,
This patch series implements the Linux Xen guest as a paravirt_ops
backend. The features in implemented this patch series are:
* domU only
* UP only (most code is SMP-safe, but there's no way to create a new vcpu)
* writable pagetables, with late pinning/early unpinning
(no shadow pagetable support)
* supports both PAE and non-PAE modes
* xen hvc console (console=hvc0)
*
2007 Apr 18
24
[patch 00/24] Xen-paravirt_ops: Xen guest implementation for paravirt_ops interface
Hi Andi,
This patch series implements the Linux Xen guest as a paravirt_ops
backend. The features in implemented this patch series are:
* domU only
* UP only (most code is SMP-safe, but there's no way to create a new vcpu)
* writable pagetables, with late pinning/early unpinning
(no shadow pagetable support)
* supports both PAE and non-PAE modes
* xen hvc console (console=hvc0)
*