search for: typesystem

...eaf.com/blog/post/44, and it doesn't seem to be working for me. I have a function: llvm::GenericValue lle_X_create_number_object(llvm::FunctionType* ft, const std::vector<llvm::GenericValue>& args) { llvm_object_structure* result = new llvm_object_structure; result->typeIdx = TypeSystem::number; result->data = reinterpret_cast<unsigned char*>(new double(args[0].DoubleVal)); llvm::GenericValue gv; gv.PointerVal = reinterpret_cast<void*>(result); return gv; } defined in an extern "C" block. I add it as a symbol with: llvm::sys::DynamicLibrary::AddS...

...ence counting. The GC documentation mentions that patch-points could be useful, but it does not state how they would be useful. If this is a FAQ, please let me know... So this is my idea at this point: The context is a C++ like language with an aggregate type that is always reference counted. The typesystem differentiate between pointers to objects that is shared between threads and those that does not. I also want a pass that turn shared_ptr to nonshared_ptr if it can be proven. So what I want to do is to wrap up all the "events" that are relevant as intrinsics and run some simplification...

...to support 16 bit floats for some operations, outside of datatypes.td and the constants class, is there anything else I will need to modify to add f16 support? probably also code generation (can't give specifics, no real expert on the LLVM codebase). this would be because, even if the core typesystem knows of the type, the codegen might not know how to emit operations on that type. now, of note: in my project (not LLVM based), float16 had not been supported directly (since it is not known to the CPU), rather, some loader and saver thunks were used which converted to/from float32 (this used...

...em to be working > for me. > > I have a function: > > llvm::GenericValue lle_X_create_number_object(llvm::FunctionType* ft, const > std::vector<llvm::GenericValue>& args) > { > llvm_object_structure* result = new llvm_object_structure; > result->typeIdx = TypeSystem::number; > result->data = reinterpret_cast<unsigned char*>(new > double(args[0].DoubleVal)); > llvm::GenericValue gv; > gv.PointerVal = reinterpret_cast<void*>(result); > return gv; > } > > defined in an extern "C" block. I add it as a symbol...

...#39;t seem to be working for me. > > I have a function: > > llvm::GenericValue lle_X_create_number_object(llvm::FunctionType* ft, const std::vector<llvm::GenericValue>& args) > { > llvm_object_structure* result = new llvm_object_structure; > result->typeIdx = TypeSystem::number; > result->data = reinterpret_cast<unsigned char*>(new double(args[0].DoubleVal)); > llvm::GenericValue gv; > gv.PointerVal = reinterpret_cast<void*>(result); > return gv; > } > > defined in an extern "C" block. I add it as a symbol wit...

I need to support 16 bit floats for some operations, outside of datatypes.td and the constants class, is there anything else I will need to modify to add f16 support? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part -------------- An HTML

...me operations, outside of > datatypes.td and the constants class, is there anything else I will > need to modify to add f16 support? > > probably also code generation (can't give specifics, no real expert > on the LLVM codebase). > this would be because, even if the core typesystem knows of the > type, the codegen might not know how to emit operations on that type. > > now, of note: > in my project (not LLVM based), float16 had not been supported > directly (since it is not known to the CPU), rather, some loader and > saver thunks were used which conve...

...ly different than what LLDB already has. On Tue, Jun 26, 2018 at 12:26 PM Jim Ingham <jingham at apple.com> wrote: > Just to be clear, by "no clang integration" do you mean "no expression > parser" or do you mean something more radical? For instance, adding a > TypeSystem and its DWARF parser for C family languages that uses a > different underlying representation than Clang AST's to store the results > would be a lot of work that wouldn't be terribly interesting to lldb. I > don't think that's what you meant, but wanted to be sure. > &g...

...C documentation mentions that patch-points could be useful, but it does not state how they would be useful. If this is a FAQ, please let me know... > > So this is my idea at this point: > > The context is a C++ like language with an aggregate type that is always reference counted. The typesystem differentiate between pointers to objects that is shared between threads and those that does not. I also want a pass that turn shared_ptr to nonshared_ptr if it can be proven. > > So what I want to do is to wrap up all the "events" that are relevant as intrinsics and run some simpl...

...o support 16 bit floats for some operations, outside of datatypes.td and the constants class, is there anything else I will need to modify to add f16 support? probably also code generation (can't give specifics, no real expert on the LLVM codebase). this would be because, even if the core typesystem knows of the type, the codegen might not know how to emit operations on that type. now, of note: in my project (not LLVM based), float16 had not been supported directly (since it is not known to the CPU), rather, some loader and saver thunks were used which converted to/from float32 (this used...

...t than what LLDB already has. >> >> On Tue, Jun 26, 2018 at 12:26 PM Jim Ingham <jingham at apple.com> wrote: >> Just to be clear, by "no clang integration" do you mean "no expression parser" or do you mean something more radical? For instance, adding a TypeSystem and its DWARF parser for C family languages that uses a different underlying representation than Clang AST's to store the results would be a lot of work that wouldn't be terribly interesting to lldb. I don't think that's what you meant, but wanted to be sure. >> >> Jim...

...t;> >> I have a function: >> >> llvm::GenericValue lle_X_create_number_object(llvm::FunctionType* ft, >> const std::vector<llvm::GenericValue>& args) >> { >> llvm_object_structure* result = new llvm_object_structure; >> result->typeIdx = TypeSystem::number; >> result->data = reinterpret_cast<unsigned char*>(new >> double(args[0].DoubleVal)); >> llvm::GenericValue gv; >> gv.PointerVal = reinterpret_cast<void*>(result); >> return gv; >> } >> >> defined in an extern "C&q...

...ould be useful, but it does >> not state how they would be useful. If this is a FAQ, please let me >> know... >> >> So this is my idea at this point: >> >> The context is a C++ like language with an aggregate type that is >> always reference counted. The typesystem differentiate between >> pointers to objects that is shared between threads and those that >> does not. I also want a pass that turn shared_ptr to nonshared_ptr if >> it can be proven. >> >> So what I want to do is to wrap up all the "events" that are rele...

Hi all, We have been thinking internally about a lightweight llvm-based ptracer. To address one question up front: the primary way in which this differs from LLDB is that it targets a more narrow use case -- there is no scripting support, no clang integration, no dynamic extensibility, no support for running jitted code in the target, and no user interface. We have several use cases internally

...> (as a matter of fact, I plan to keep typed pointers in llvmlite, > because they provide invaluable help discovering bugs early rather than > late - i.e. giving a proper error rather than crashing mysteriously) > I wholeheartedly agree: IMO, all LLVM front-ends should attach their own typesystem information to LLVM values instead of passing bare Value* around, or the textual equivalent, in your case. In rustc we didn't do this from the start and it's become a complete nightmare to work with those old parts of the codebase. > Regards > > Antoine. > > > _________...

...les</a></li> <li><a href="#volatile">Volatile Memory Accesses</a></li> + <li><a href="#memmodel">Memory Model for Concurrent Operations</a></li> </ol> </li> <li><a href="#typesystem">Type System</a> @@ -1470,8 +1471,93 @@ </div> +<!-- ======================================================================= --> +<h3> + <a name="memmodel">Memory Model for Concurrent Operations</a> +</h3> + +<div> + +<p>...

...ype like TypeAlias - I couldn't find one. Here I have no ability to set a name with a Type: vector< const Type * > tvec = { Type::IntTy }; Type * ty = StructType::get( tvec ); But what I wanted to say is that they are the same type. This structural type system (compared to nominal typesystems) is very intersting and has good support for optimizations. But sometimes it would be interesting to actually get symbol information about a type beeing used, without the need for full featured debug information ala DWARF. This could be also solved by introducing Annotable. For instance if the a...

On Oct 23, 2007, at 05:52, BGB wrote: > I am assuming then that some external assembler is used (such as > 'gas')?... In the static compilers, yes. The JIT directly serializes instructions into memory without the aid of an external assembler. There are also experimental built-in assemblers; LLVM calls them object writers[1]. > it looks like much of the interconnection

...a big text buffer), while another part winds back up potentially building a very different representation of the data (for example, the upper compiler is based around trees, where the lower compiler is more based around buffers and flat arrays, and doing funky bit-twiddling to cram much of the typesystem mechanics into a single 32bit integer...). it is also a lot easier to make changes to the printer or parser, than to go through the horrid pain of changing around a bunch of structs and/or having to modify a bunch of code for seemingly trivial alterations... this was in fact a major reason for...

well, as it so seems I need to bother everyone on the list with my pointless newb crap, but here goes. maybe there was a FAQ for all this, but I missed it. well, I am not trying to demean LLVM in any way here, only trying to understand and evaluate things from my POV is all... sorry if at all I seem arrogant or condescending... well, running a linecounter, it is about 223 kloc (c++ ...), +