similar to: [LLVMdev] Geting the size of a structure?

On Thu, 2005-04-21 at 17:56 -0400, Evan Jones wrote: > How does LLVM-GCC emit the correct size for structures? Is structure > packing part of the "platform specific" magic that GCC knows, or is > there some "portable" way to put a structure size into LLVM byte code? > > Actually, I don't care if it is portable, as long as LLVM has some way > to compute

On Sep 22, 2009, at 4:49 PM, Talin wrote: > > // Calculate the size of the specified LLVM type. > Constant * DebugInfoBuilder::getSize(const Type * type) { > Constant * one = ConstantInt::get(Type::Int32Ty, 1); > return ConstantExpr::getPtrToInt( > ConstantExpr::getGetElementPtr( > ConstantPointerNull::get(PointerType::getUnqual(type)), >

On 29 Apr 2006 20:38:58 -0600, Tom Tromey <tromey at redhat.com> wrote: > >>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: > > >> In the JIT, devirtualization looks doable, though somewhat fiddly. At > >> least, that is true for straightforward things like calls to methods > >> in final classes, or calls to

Alkis Evlogimenos wrote: > On Wed, 2004-06-09 at 04:56, Vladimir Prus wrote: > > Hello! > > Is there an (semi)automatic way to save registers used by a function? For > > example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For > > now I just emit huge prologue code to push them all to stack -- even if > > they are not modified at all. > > >

On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > > After to speaking to Devang and a number of other people at the developer's > conference, I was able to make some forward progress on getting debugging to > work. I'm now able to actually single-step through my program and set > breakpoints,

On Sat, 2005-08-27 at 11:47 -0700, Reid Spencer wrote: > Alkis Evlogimenos wrote: > > It seems that these two classes are the same... Maybe they should be > > merged into 1 class? > > > I think you're looking at something old. MutexLocker doesn't exist any more. llvm/Support/ThreadSupport.h is not generated anymore? -- Alkis

On Tue, Jul 20, 2010 at 2:46 PM, Talin <viridia at gmail.com> wrote: > On Tue, Jul 20, 2010 at 8:34 AM, Chris Lattner <clattner at apple.com> wrote: > >> >> On Jul 20, 2010, at 1:36 AM, Anton Korobeynikov wrote: >> >> >> used to make the code manipulating the union type "well typed". This >> >> approach seems work very well, is

It seems that these two classes are the same... Maybe they should be merged into 1 class? -- Alkis

Is there a way to get the sizeof a type? Say I've created a struct type without any explicit attribtues, and I want to call malloc() to allocate space for it. Can I get the size as an llvm::Constant* (or other llvm::Value*) given an llvm::StructType* or other llvm::Type*? TIA, -- Rick

Hi all, consider the following function from Core.cpp in LLVM 9.0.0: LLVMValueRef LLVMBuildMalloc(LLVMBuilderRef B, LLVMTypeRef Ty, const char *Name) { Type* ITy = Type::getInt32Ty(unwrap(B)->GetInsertBlock()->getContext()); Constant* AllocSize = ConstantExpr::getSizeOf(unwrap(Ty)); AllocSize = ConstantExpr::getTruncOrBitCast(AllocSize, ITy);

Vladimir Prus wrote: > Vladimir Prus wrote: > > The above-mentioned test contains this: > > > > long B53 = - (1LL << 53); > > > > strictly speaking, this is not correct code. The C standard says about > > shift: "if the value of the first operator is ... or greater than ... the > > width of the promoted left operand, the behaviour is

For the size of a type to be calculated at runtime, there is a known trick with gep. Is there any similar trick for determining the alignment of a type at runtime for target-independent IR? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/887f8612/attachment.html>

<algorithm> works too. On Fri, 24 Sep 2004 10:09:21 -0500 Alkis Evlogimenos <alkis at cs.uiuc.edu> wrote: > On Fri, 2004-09-24 at 09:43, Paolo Invernizzi wrote: > > Jeff Cohen wrote: > > > > >But I compiled that under vc7.1 as it was! > > > > > > > > ;-(( > > > > Probably is an implicid includes, but I'm using the

Chris Lattner wrote: >I think that we should switch to C constants in this case. Can you try >#include <math.h> and use HUGE_VAL instead? > It works: [finna at coplin11 ~/test]$ cat tst.cpp #include <limits> #include <iostream> #include <math.h> int main() { std::cerr << std::numeric_limits<float>::infinity() << "\n"; std::cerr

On Thu, May 06, 2004 at 04:06:27PM +0200, Finn S Andersen wrote: > Chris Lattner wrote: > > >I think that we should switch to C constants in this case. Can you try > >#include <math.h> and use HUGE_VAL instead? > > > It works: > > [finna at coplin11 ~/test]$ cat tst.cpp > #include <limits> > #include <iostream> > #include

On Thu, 2004-07-08 at 07:07, Vladimir Prus wrote: > Vladimir Prus wrote: > > Vladimir Prus wrote: > > > The above-mentioned test contains this: > > > > > > long B53 = - (1LL << 53); > > > > > > strictly speaking, this is not correct code. The C standard says about > > > shift: "if the value of the first operator is ... or

On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: > On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > >> After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now

On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: > > On Sep 22, 2009, at 4:49 PM, Talin wrote: > >> >> // Calculate the size of the specified LLVM type. >> Constant * DebugInfoBuilder::getSize(const Type * type) { >> Constant * one = ConstantInt::get(Type::Int32Ty, 1); >> return ConstantExpr::getPtrToInt( >>

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: >> In the JIT, devirtualization looks doable, though somewhat fiddly. At >> least, that is true for straightforward things like calls to methods >> in final classes, or calls to methods on objects allocated with 'new' >> in the current function. (The latter could be

On 08/09/05, Alkis Evlogimenos <evlogimenos at gmail.com> wrote: > to those coalesced registers, it is logical that noone will ever query > the liveness of those registers (unless there is a bug somewhere in the Indeed the coalesced registers may logically not be queried since they do not appear in any operand list of the machine code, but the VarInfo::DefInst in VirtRegInfo of the