similar to: [LLVMdev] Anonymous Structures

Displaying 20 results from an estimated 7000 matches similar to: "[LLVMdev] Anonymous Structures"

2009 Apr 29
0
[LLVMdev] Anonymous Structures
On 2009-04-29, at 10:53, Nick Johnson wrote: > I am writing a pass which must insert calls to an external library. > One of the parameters to functions in this library is a very large, > complex structure (let's call it Foo). [...] The internal > representation of Foo is important to this library, but the code my > pass generates will only deal with Foo-pointers. >
2018 Aug 25
3
PATypeHolder, refineAbstractTypeTo(), addTypeName not found
I am following the code of the project https://llvm.org/svn/llvm-project/java/trunk/lib/Compiler/Resolver.cpp, But some class/function of it is not present in my source code due to replacement of this function in newer llvm verion. Can someone please suggest me the alternative approach of these function in latest llvm version. Here are those classes and functions : 1) PATypeHolder 2)
2008 Sep 12
2
[LLVMdev] Order of fiels and structure usage
I'd like to be able to make use of a structure type and its fields before it is completely defined. To be specific, let me ask detailed questions at various stages in the construction of a recursive type. I copy from http://llvm.org/docs/ProgrammersManual.html#TypeResolve // Create the initial outer struct PATypeHolder StructTy = OpaqueType::get(); Is it possible to declare
2008 Jun 13
1
[LLVMdev] code generation order revisited.
On Thu, 12 Jun 2008 16:05:19 -0400, Gordon Henriksen wrote: > > Partially opaque types can be refined. This section of the programmer's > manual is applicable: > > http://llvm.org/docs/ProgrammersManual.html#BuildRecType > > — Gordon Here it is: : // Create the initial outer struct : PATypeHolder StructTy = OpaqueType::get(); : std::vector<const Type*> Elts; :
2008 Jun 12
0
[LLVMdev] code generation order revisited.
On Jun 12, 2008, at 13:25, Hendrik Boom wrote: > So it appears that types are processed for identity the moment they > are made during parse tree construction? Yes. > This means that a type has to be completely known on creation. Yes. > Presumably there's some mechanism tor a type that isn't completely > known yet -- or is thet avoided by having a type
2018 Jun 12
2
Proper method to initialize all LLVM Internal Data Structures?
Hi: I'm building a small tool on top of LLVM Core Library. ``` LLVMContext context; SMDiagnostic diag; Module *M = parseIRFile(InputIR, diag, context).get(); if (M == nullptr) { diag.print("LLVM", errs()); exit(-1); } assert(M->isMaterialized() && "Module not materialized!"); PointerType *ArrayPtrTy =
2009 May 07
3
[LLVMdev] Set alignment of a structure?
Hello, Is it possible to set the alignment of a StructType in llvm? Especially in the case that it may contain OpaqueTypes? Thanks, -- Nick Johnson
2008 Jun 12
2
[LLVMdev] code generation order revisited.
>> >> I think I may have found an exception to this -- the API seems to >> require me to have all the fields for a struct ready before I >> construct the struct. I don't have the ability to make a struct >> type, use it to declare some variables, and still contribute fields >> to it during the rest of the compilation. >> >> Is there a
2011 Jul 19
0
[LLVMdev] dragonegg svn still broken
On Tue, Jul 19, 2011 at 10:12:47AM +0100, Jay Foad wrote: > On 18 July 2011 15:23, David Blaikie <dblaikie at gmail.com> wrote: > > Looks like that break came > > from http://llvm.org/viewvc/llvm-project?view=rev&revision=135154 > > Judging by this ArrayRef ctor you should be able to simplify those calls by > > changing the last two arguments from
2005 Mar 08
0
[LLVMdev] Recursive Types using the llvm support library
On Mon, 7 Mar 2005, John Carrino wrote: > As far as I can tell, when you construct a type using the support > library StructType::get, you have to pass in a list of types. How can > you make a Recursive type by passing in a pointer to the type you are > constucting. > > An example where something really simple like the line below was output > would be perfect. > >
2005 Mar 08
2
[LLVMdev] Recursive Types using the llvm support library
>> An example where something really simple like the line below was output >> would be perfect. >> >> %struct.linked_list = type { %struct.linked_list*, %sbyte* } > > Use something like this: > > PATypeHolder StructTy = OpaqueType::get(); > std::vector<const Type*> Elts; > Elts.push_back(PointerType::get(StructTy)); >
2008 Oct 03
0
[LLVMdev] Making Sense of ISel DAG Output
On Fri, October 3, 2008 9:10 am, David Greene wrote: > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection >> loads have multiple uses, so even though you've managed to match a >> larger pattern that incorporates them, they still need to exist to >> satisfy some other users. > > Yes,
2005 Mar 09
4
[LLVMdev] Recursive Types using the llvm support library
----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, March 08, 2005 6:31 PM Subject: Re: [LLVMdev] Recursive Types using the llvm support library > On Tue, 8 Mar 2005, Vladimir Merzliakov wrote: > >>>> An example where something really simple like the
2012 Jul 06
2
[LLVMdev] Self-referential function pointer
Hey guys, I could use some advice on a special case of a function pointer as a formal argument. I would like the function pointer type to contain the actual signature of the function, i.e. not a pointer to var args function. This becomes an issue when I have a function which can take a pointer to itself as an argument... our terminology for this is "a recursive procedure". That is, of
2008 Oct 03
3
[LLVMdev] Making Sense of ISel DAG Output
On Thursday 02 October 2008 19:32, Dan Gohman wrote: > Looking at your dump() output above, it looks like the pre-selection > loads have multiple uses, so even though you've managed to match a > larger pattern that incorporates them, they still need to exist to > satisfy some other users. Yes, I looked at that too. It looks like these other uses end up being chains to
2010 Jun 14
2
[LLVMdev] Adding fields in a already built type?
Hi, We build a type with StructType::get(fModule->getContext(), fDspFields, false); with a fDspFields (std::vector<const llvm::Type*> fDspFields;) that is not yet completely known when we have to build the type. It is possible to add fields in a already build type? Thanks Stéphane Letz
2010 Jun 14
0
[LLVMdev] Adding fields in a already built type?
On Jun 14, 2010, at 1:22 PM, Stéphane Letz wrote: > Hi, > > We build a type with StructType::get(fModule->getContext(), fDspFields, false); with a fDspFields (std::vector<const llvm::Type*> fDspFields;) that is not yet completely known when we have to build the type. It is possible to add fields in a already build type? Nope, types are immutable once created. The only
2018 Aug 24
3
OpaqueType:: get()
I have code that uses OpaqueType::get(), it was used to be in llvm/IR/DerivedType.h , but it is removed now. What should I use for it replacement. Also, it is using #include <llvm/Bytecode/WriteBytecodePass.h> , but I do not found any WriteBytecodePass.h in my source code. Please tell me, what should I use in replacement of these. Thanks& Regards, Ratnesh Tiwari -------------- next
2009 Sep 15
0
[LLVMdev] Opaque types in function parameters
2009/9/15 Carlos Sánchez de La Lama <carlos.delalama at urjc.es>: > Hi all, > > I am creating a function and trying to call it using the LLVM API. It > seems that whenever the function type includes an opaque-typed > parameter, the CallInst::Create call causes an assert: > > Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) > ==
2005 Mar 08
0
[LLVMdev] Recursive Types using the llvm support library
On Tue, 8 Mar 2005, Vladimir Merzliakov wrote: >>> An example where something really simple like the line below was output >>> would be perfect. >>> >>> %struct.linked_list = type { %struct.linked_list*, %sbyte* } >> >> Use something like this: >> >> PATypeHolder StructTy = OpaqueType::get(); >> std::vector<const