similar to: [LLVMdev] Can the structure, having few integers and 'opaque', be manipulated upon?

I'm building a StructType without a body using StructType *StructType::create(LLVMContext &Context, StringRef Name); and then later adding a body to with setBody(). It starts of isOpaque() == true, and isSized() == false, and after I add the body, isOpaque() == false, but isSized() is still false. If I create a StructType using StructType * StructType ::create(LLVMContext

Hi Rick, On 22/01/13 09:04, Rick Mann wrote: > I'm building a StructType without a body using > > StructType *StructType::create(LLVMContext &Context, StringRef Name); > > and then later adding a body to with setBody(). It starts of isOpaque() == true, and isSized() == false, and after I add the body, isOpaque() == false, but isSized() is still false. this is the standard

I think I found it. In InstCombiner::ComputeMaskedBits we have the following lines: if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) { unsigned Align = GV->getAlignment(); if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) Align = TD->getPrefTypeAlignment(GV->getType()->getElementType()); It assumes that global

Hi Nicolas, > if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) { > > unsigned Align = GV->getAlignment(); > > if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) > > Align = TD->getPrefTypeAlignment(GV->getType()->getElementType()); > > It assumes that global values are always optimally

This needs to be applied as well. Thanks, Reid. -----Forwarded Message----- > From: Morten Ofstad <morten at hue.no> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: [LLVMdev] GetElementPtr for packed types and VS build > Date: Wed, 01 Dec 2004 15:10:49 +0100 > > As I was working with packed types it became apparent that I sometimes >

Hi Evan, > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > unsigned Alignment = expr_align(exp) / 8 > > It's using the alignment of the expression, rather than the memory > object of LValue. can't you just use expr_align(lhs) instead? > The patch saves the alignment of the memory object in LValue returned > by EmitLV().

Victor Zverovich wrote: > Dear all > > I am trying to get the size of an LLVM pointer type. > getPrimitiveSizeInBits() returns 0 for it and the documentation for > isSized() suggest to use TargetData. > I figured out from Kaleidoscope example that one can get a pointer to > TagetData object through the execution engine but it seems to be an > overkill. > What is the

For those targets supported by LLVM, you can get their TargetData by creating TargetMachine first (take X86 as example): ==== BEGIN CODE SNIPPET ==== const std::string TripleStr = "i686-unknown-linux"; // hard coded for example const std::string FeatureStr = ""; // hard coded for example std::string Err; const Target* T; TargetMachine* TM = NULL; const

Hi Duncan, I see. I didn't know GlobalValue had a method for changing the alignment (and that 0 meant natural alignment). Explicitly calling setAlignment works like a charm. So it's not an LLVM bug. Thanks, Nicolas -----Original Message----- From: Duncan Sands [mailto:baldrick at free.fr] Sent: Thursday, 10 July, 2008 14:41 To: llvmdev at cs.uiuc.edu Cc: Nicolas Capens Subject: Re:

Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =

Hi Fabian, > I am somewhat confused by the following method within the LLVM, > especially the lines > "confusion starts" -> "confusion ends" are hard to follow. yes, this seems like a wart. It has been there ever since Chris added the getPreferredAlignmentLog method in commit 25978. Maybe he can comment on whether the code to bump up the alignment for big

Hello everybody, I am somewhat confused by the following method within the LLVM, especially the lines "confusion starts" -> "confusion ends" are hard to follow. Maybe the idea is that if there are such big data structures one does not waste much memory anyway if they are aligned to a 16-byte boundary. However, my assembler complains here because it only supports 1-, 2-,

I am new to LLVM and couldn't find any llvm-user list, so I am posting my user question here, sorry. I am trying to create a simple "puts" call accepting the static string, with the code below. The last line (CallInst::Create) fails with an assert: "Calling a function with a bad signature!" Because the type of function is void(u8*) and the argument supplied is:

On Wednesday 18 February 2009 21:43, Dan Gohman wrote: > I agree, that doesn't look right. It looks like this > is what was intended: > > Index: lib/CodeGen/SelectionDAG/DAGCombiner.cpp > =================================================================== > --- lib/CodeGen/SelectionDAG/DAGCombiner.cpp (revision 65000) > +++ lib/CodeGen/SelectionDAG/DAGCombiner.cpp

On Mar 9, 2011, at 8:40 AM, Duncan Sands wrote: > Hi Fabian, > >> I am somewhat confused by the following method within the LLVM, >> especially the lines >> "confusion starts" -> "confusion ends" are hard to follow. > > yes, this seems like a wart. It has been there ever since Chris added the > getPreferredAlignmentLog method in commit

On Feb 20, 2009, at 3:05 PM, David Greene wrote: > On Wednesday 18 February 2009 21:43, Dan Gohman wrote: >> I agree, that doesn't look right. It looks like this >> is what was intended: >> >> Index: lib/CodeGen/SelectionDAG/DAGCombiner.cpp >> =================================================================== >> ---

Dear all I am trying to get the size of an LLVM pointer type. getPrimitiveSizeInBits() returns 0 for it and the documentation for isSized() suggest to use TargetData. I figured out from Kaleidoscope example that one can get a pointer to TagetData object through the execution engine but it seems to be an overkill. What is the right way to do it? Best regards, Victor -------------- next part

On Mon, Mar 15, 2010 at 11:51:47AM +0000, Tim Northover wrote: > Hello, > > I noticed a bit of a gap in the current code for unions: a > ConstantUnion cannot be written out to .ll. I've been continuing plugging gaps as I find them, which might not be the best way to solve this problem, but it has produced something that seems to do roughly what I expect. I've split it into

After I manually modified .ll file deleting %0 I am getting this error from llvm-as: lvm-as: my.ll:43:3: error: instruction expected to be numbered '%0' %1 = tail call noalias i8* @malloc(i32 8) nounwind ; <i8*> [#uses=1] ^ So now I have to also rename all other %<NUM> variables? Why llvm is so strict with naming? I think it should just accept whatever names are there

Hi all, I am writing a llvm backend for a small stream processor. Because of its special application field, the processor does not support function. When I built the llvm backend for the new target, I leave the calling convention and frame lowering part blank. It compilered correctly, but I encountered execution errors, like *[xxx at localhost ex]$ llc test.ll -march=SSP -o test.s 0 llc