Displaying 20 results from an estimated 30000 matches similar to: "[LLVMdev] Some question on LLVM design"
2004 Oct 23
0
[LLVMdev] Some question on LLVM design
On Fri, Oct 22, 2004 at 03:18:00PM +0200, Marc Ordinas i Llopis wrote:
> I'm currently looking at LLVM as a possible back-end to a dynamic
> programming system (in the tradition of Smalltalk) we are developing.
Neat!
> I have read most of the llvmdev archives, and I'm aware that some
> things are 'planned' but not implemented yet. We are willing to
> contribute
2004 Oct 24
0
[LLVMdev] Some question on LLVM design
On Fri, 22 Oct 2004, Marc Ordinas i Llopis wrote:
> Hi everybody,
Hi!
> I'm currently looking at LLVM as a possible back-end to a dynamic
> programming system (in the tradition of Smalltalk) we are developing. I
Very cool!
> have read most of the llvmdev archives, and I'm aware that some things
> are 'planned' but not implemented yet. We are willing to
2004 Oct 25
2
[LLVMdev] Some question on LLVM design
Misha Brukman wrote:
>
>>1. Opcodes and intrinsics
>>
> That's not really correct. The intrinsics such as llvm.frameaddress and
> llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of
> the intrinsics is specifically machine-dependent, and LLVM (and its
> opcodes) are machine-independent, so there is no valid interchange of
> these intrinsics
2005 Mar 11
2
[LLVMdev] Linking LLVM code with LLVM
Hi all,
Sorry if this is obvious.
I'm trying to link LLVM-generated code with LLVM itself, and don't know
how to do it. Just as a little test, I've tried compiling the example
HowToUseJIT.cpp using llvm-g++, but I get tons of errors.
Is there an easy way of doing this? Has anyone tried it before?
Thanks,
Marc Ordinas i Llopis | Tragnarion Studios
2004 Oct 25
1
[LLVMdev] Some question on LLVM design
Thanks all for the fast answers, I'm certainly understanding LLVM
better. Some more comments below:
Chris Lattner wrote:
>>Couldn't the front-end just produce stores/volatile stores and then a
>>compilation pass transform them into a write-barrier if necessary?
>
>
> Sortof. The problem with this is that (without gcwrite) there is no way
> to identify the
2005 Mar 14
2
[LLVMdev] Linking LLVM code with LLVM
Excuse the long post,
Chris Lattner wrote:
> On Fri, 11 Mar 2005, Marc Ordinas i Llopis wrote:
>
>> Sorry if this is obvious.
>> I'm trying to link LLVM-generated code with LLVM itself, and don't
>> know how to do it. Just as a little test, I've tried compiling the
>> example HowToUseJIT.cpp using llvm-g++, but I get tons of errors.
>>
>>
2005 Mar 16
0
[LLVMdev] Linking LLVM code with LLVM
On Mon, 14 Mar 2005, Marc Ordinas i Llopis wrote:
> Finally, I tried first generating the .o (bytecode) file, and then linking
> got me the same result.
>
> So, I'm really stuck here. Is there a way of linking LLVM-produced code with
> LLVM? Has anyone tried it before?
I guess I don't really understand what your goal is. Currently our
support for transparently mixing
2005 Mar 13
0
[LLVMdev] Linking LLVM code with LLVM
On Fri, 11 Mar 2005, Marc Ordinas i Llopis wrote:
> Sorry if this is obvious.
> I'm trying to link LLVM-generated code with LLVM itself, and don't know how
> to do it. Just as a little test, I've tried compiling the example
> HowToUseJIT.cpp using llvm-g++, but I get tons of errors.
>
> Is there an easy way of doing this? Has anyone tried it before?
What sort of
2004 Oct 24
2
[LLVMdev] Some question on LLVM design
On Sat, 23 Oct 2004, Misha Brukman wrote:
> > A possible view of intrinsics could be "operations that don't depend
> > on the target architecture, but instead on the language runtime". But
> > then wouldn't malloc/free be intrinsics?
>
> Good question. Due to the amount of pointer/data analysis in LLVM, it
> is often necessary to consider memory
2009 Mar 01
2
[LLVMdev] Why LLVM should NOT have garbage collection intrinsics
Gordon Henriksen wrote:
>
> The "runtime interface" is a historical artifact. LLVM does not impose
> a runtime library on its users. I wouldn't have a problem deleting all
> mention of it, since LLVM does not impose a contract on the runtime.
>
Excellent, I found it somewhat unhelpful!
>> The semantics of llvm.gcroot are vague:
>> "At
2009 Feb 27
1
[LLVMdev] Why LLVM should NOT have garbage collection intrinsics[MESSAGE NOT SCANNED]
Hi,
I realise this might be a bit controversial ;)
Suppose I am writing a VM (such as VMKit), or a VM toolkit, and I want
to add a generational GC.
If I want to use the llvm.gcwrite intrinsic for my write barrier then
I need to write a GC and then implement for each and *every* backend the
gcwrite intrinsic for my write barrier.
Now, if I don't use the intrinsic, I need to write my write
2009 Feb 27
2
[LLVMdev] Garbage collection
Mark Shannon wrote:
> Jon Harrop wrote:
>> On Thursday 26 February 2009 17:25:56 Chris Lattner wrote:
>>> In my ideal world, this would be:
>>>
>>> 1. Subsystems [with clean interfaces] for thread management,
>>> finalization, object model interactions, etc.
>>> 2. Within different high-level designs (e.g. copying, mark/sweep, etc)
>>>
2009 Feb 27
2
[LLVMdev] Why LLVM should NOT have garbage collection intrinsics
Gordon Henriksen wrote:
> Hi Mark,
>
> I don't think anyone will dispute that it's easier to hack up a shadow
> stack (or plug into a conservative collector) to get up and running
> with GC. That is absolutely the route to go if portability trumps
> performance.
Why? LLVM is all about portability AND performance.
>
> If you review the mailing list history,
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) {
> > return *FieldPtr;
> > }
>
> Hm, but doesn't FieldPtr need to be calculated target-specific in those
> cases?
For the field pointer, one could use the getelementptr instruction:
%pairty = { sbyte, sbyte, int* }
%pairPtr = ...
%fieldptr = getelementptr
2004 Jul 21
0
[LLVMdev] GC questions.
Ok, that makes sense :).
, Tobias
On Wed, 21 Jul 2004, Chris Lattner wrote:
> On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) {
> > > return *FieldPtr;
> > > }
> >
> > Hm, but doesn't FieldPtr need to be calculated target-specific in those
> > cases?
>
> For the field pointer, one
2009 Feb 27
0
[LLVMdev] Why LLVM should NOT have garbage collection intrinsics
On Feb 27, 2009, at 12:56, Mark Shannon wrote:
> Gordon Henriksen wrote:
>
>> The ultimate endgoal is to support schemes with still-lower
>> execution overhead. The next step for LLVM GC would be elimination
>> of the reload penalty for using GC intrinsics with a copying
>> collector. This, again, requires that the code generator perform
>> bookkeeping
2009 Mar 01
0
[LLVMdev] Why LLVM should NOT have garbage collection intrinsics
On 2009-03-01, at 05:41, Mark Shannon wrote:
> Gordon Henriksen wrote:
>
>>> The semantics of llvm.gcroot are vague: "At compile-time, the code
>>> generator generates information to allow the runtime to find the
>>> pointer at GC safe points."
>>>
>>> Vague, ill-specified interfaces are worse than none.
>>
>>
2017 Feb 14
2
Adding FP environment register modeling for constrained FP nodes
Hi Hal,
Thanks for the guidance. I hope you don’t mind that I’m adding LLVMDev to this e-mail thread, as it seems as though it may be of general interest.
I agree that duplicating the FP opcodes should be our goal. I just wasn’t sure that was entirely possible. I’ll try adding implicit defs in the way you’ve suggested, but I’m concerned that there may be code that relies on the TII for that
2007 Jul 23
2
[LLVMdev] LHS of an expression
Hi Bill,
Thanks a lot for your response.But my problem still remains.The thing is i
am having a data type std::vector<Value*> as i am checking for the
variables in Store Instructions and Malloc Instructions.For store the case
is straightforward as discussed earlier.I want the same Value* variable
for malloc inst as well.
bcos i cannot have a different set for only instructions.
can there be
2015 Dec 01
10
[RFC] Intrinsic naming convention (words with dots)
Hi everyone,
We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When