Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] portable way to modify the FP register?"
2010 Dec 13
0
[LLVMdev] portable way to modify the FP register?
Hi,
To add to what Anton said, what if you're on a non-x86 target, or --no-frame-pointer is set?
Also, I'm intrigued as to how you guarantee that in the intervening time between the coroutine/generator function bar() returning one result and the next invocation of bar(), foo() doesn't call another function and overwrite bar()'s stack frame?
Cheers,
James Molloy
Graduate
2010 Dec 13
2
[LLVMdev] portable way to modify the FP register?
Hi again,
On Dec 13, 2010, at 18:03, James Molloy wrote:
> To add to what Anton said, what if you're on a non-x86 target, or --no-frame-pointer is set?
for the moment we're only considering X86-64 targets and we're forcing the FP to be materialized (ie, -disable-fp-elim) to ensure we can be independent of what happens to SP.
btw, I can't think of any current ISA/ABI which
2006 Jul 14
6
Get a collection through ActiveRecord for using with option_groups_from_collection_for_select
Hello,
I am having some difficulties with ActiveRecord.
What I want to do is to get a collection of SubjectGroups for using
with option_groups_from_collection_for_select
My Code:
========================================
class Subject < ActiveRecord::Base
has_and_belongs_to_many :users
belongs_to :subject_group
end
class SubjectGroup < ActiveRecord::Base
has_many :subjects
end
2016 Jul 15
2
RFC: Coroutine Optimization Passes
Hi all:
I've included below a brief description of coroutine related optimization
passes and some questions/thoughts related to them. Looking forward to your
feedback, comments and questions.
Thank you!
Roadmap:
========
1) Get agreement on coroutine representation and overall direction.
.. repeat 1) until happy
http://lists.llvm.org/pipermail/llvm-dev/2016-June/100838.html (Initial)
2016 Jun 09
6
Fwd: [RFC] LLVM Coroutines
Hi all:
Below is a proposal to add experimental coroutine support to LLVM. Though this
proposal is motivated primarily by the desire to support C++ Coroutines [1],
the llvm representation is language neutral and can be used to support
coroutines in other languages as well.
Clang + llvm coroutines allows you to take this code:
generator<int> range(int from, int to) {
for(int i =
2011 Jul 28
4
[LLVMdev] [RFC] Coroutines
Hi llvmdev!
I've been working on adding coroutines to LLVM. Mentioned below is the
implementation plan I'm following, for suggestions, flames and other
input. Using segmented stacks is a prerequisite.
The idea is to associate every coroutine with a coroutine descriptor. A
coroutine descriptor consists of four words: w0, w1, w2 and w3.
w0 always contains the _launcher_, and invoking a
2016 Jul 21
2
RFC: LLVM Coroutine Representation, Round 2
cc llvm-dev
On Thu, Jul 21, 2016 at 9:57 AM, Vadim Chugunov <vadimcn at gmail.com> wrote:
> Hi Gor,
> Does you design support resumption with parameter(s)? (such as Python's
> generator.send(x)). I suppose the "promise" could be used for passing data
> both ways, but if that's the plan, please mention this explicitly in the
> design doc.
> Also, how is
2016 Jun 15
2
[RFC] LLVM Coroutines
Hi Sanjoy,
>> I'm not familiar with fiber-type APIs, but I assume fiber_fork is like
>> setjmp, in that it can "return twice"?
Yes, user-mode stack switching API are somewhat similar to setjmp. Here are
links to a doc page and implementation, just in case you are curious:
http://www.boost.org/doc/libs/1_59_0/libs/context/doc/html/context/context.html
2016 Jun 12
2
[RFC] LLVM Coroutines
(Dropped llvm-dev by accident. Putting it back)
HI Eli:
>> coro.barrier() doesn't work: if the address of the alloca doesn't escape,
>> alias analysis will assume the barrier can't read or write the value of
>> the alloca, so the barrier doesn't actually block code movement.
Got it. I am new to this and learning a lot over the course
of this thread. Thank you
2011 Aug 04
0
[LLVMdev] [RFC] Coroutines
On 07/28/2011 05:31 PM, Sanjoy Das wrote:
> Hi llvmdev!
>
> I've been working on adding coroutines to LLVM. Mentioned below is the
> implementation plan I'm following, for suggestions, flames and other
> input. Using segmented stacks is a prerequisite.
I think my only comment is that, while this would probably work,
implementing it in C with a bit of assembly for
2010 Mar 21
6
Do i really need Dahdi and Libpri.
Hy guys i am having so much hard time to setup asterisk on a virtual machine that i got , i just want to know if i really need to use Dahdi and libpri on a complete Digital PBX i just gonna use sip and iax.
I will never use any kind of analog line on this machine.
Wait for a feed back.
Daniel Abreu.
2018 Jan 10
3
RFC: attribute synthetic("reason")
Summary
I would like to propose that we add the following function attribute to LLVM:
synthetic(<string>)
This attribute can only be applied to functions. It is not a semantic statement about the function it decorates. It is, instead, an explicit directive to LLVM to not attempt to propagate information about the function body outside of the function, including by changing the
2016 Jul 15
4
RFC: Coroutine Optimization Passes
Hi David:
>> How do you deal with basic blocks which appear to be used by multiple parts
>> of the coroutine? We handled this in WinEHPrepare by cloning any BBs which
>> were shared.
I experimented with several approaches, but, cloning ended up being the simplest
and most reliable. Suspend points express three different control flows that
can happen at the suspend point: a
2016 May 22
2
Paquete calculo de tamaño muestral
Hola a todos:
Necesito saber si alguien tiene alguna idea de un paquete con múltiples
funciones (cálculos) para determinar el tamaño de la muestra
(particularmente de estudios de psicología y ciencias sociales).
De antemano agradezco la atención. Saludo desde Brasil
*Guilherme Amorim Homem de Abreu Loureiro*
Agronomist Engineer
*CREA-BA: 051511013-2*
Master of Science in Crop Production, Soil
2019 Dec 26
2
[RFC] Coroutines passes in the new pass manager
Hello all,
It's been a month since my previous email on the topic, and since then
I've done some initial work on porting the coroutines passes to the
new pass manager. In total there are 6 patches -- that's a lot to
review, so allow me to introduce the changes being made in each of
them.
# What's finished
In these first 6 patches, I focused on lowering coroutine intrinsics
2016 Jun 11
4
[RFC] LLVM Coroutines
On Fri, Jun 10, 2016 at 5:25 PM, Gor Nishanov <gornishanov at gmail.com> wrote:
> Hi Eli:
>
> >> Naively, you would expect that it would be legal to hoist the store...
> >> but that breaks your coroutine semantics because the global could be
> mutated
> >> between the first return and the resume.
>
> Hmmm... I don't see the problem. I think
2018 Jan 12
0
RFC: attribute synthetic("reason")
That all makes sense.
I don't think the name "synthetic" is all that intuitive, though. Enum
attributes are pretty cheap, maybe we should try to use a name closer to
what we're trying to implement? For example, we could add a new
"coroutine_foo" attribute for every coroutine style we implement. We
would have analysis helper functions to answer questions like "is
2016 Jun 13
3
[RFC] LLVM Coroutines
Hi Sanjoy:
>> Now in the above CFG %val can be folded to 10, but in reality you need
>> a PHI of 10 and 20
Quick answer: folding %val to 10 is OK, but, I would prefer it to be 'undef'
or even catch it in the verifier as it is a programmer/frontend error.
Details are in the second half of my reply. I would like to start
with the thought experiment you suggested, as it might
2016 Jun 12
2
[RFC] LLVM Coroutines
Hi Eli:
>> Block1:
>> %0 = call i8 coro.suspend()
>> switch i8 %0, label suspend1 [i8 0 %return] ; or icmp + br i1
>> Suspend1:
>> switch i8 %0, label %resume1 [i8 1 %destroy1] ; or icmp + br i1
>>
>> This doesn't look right: intuitively the suspend happens after the return
>> block runs.
Perhaps, but, that is not the intended
2011 May 04
2
[LLVMdev] Greedy register allocation
On May 4, 2011, at 8:23 AM, Evan Cheng wrote:
>> I don't know how realistic it is to model the loop buffer in the register allocator, but this would a very interesting thing to try to optimize for in a later pass. If an inner loop "almost" fits, then it would probably be worth heroic effort to try to reduce the size of it to shave off a few bytes.
>
> Jakob and I have