similar to: [LLVMdev] Equivalent alignment of __attribute__((__aligned__))

On Feb 1, 2010, at 11:06 AM, Garrison Venn wrote: > Is there a way using llvm::TargetData to determine the alignment of what would be equivalent > to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the > target platform so that I know what the max alignment of an address returned by malloc(...) will > be. Not currently. The alignment

Sorry as you interpreted I meant minimum alignment. My issue is in translating from a C struct which has a member aligned with __attribute__((__aligned__)) to a generated packed StructType where I use padding to force the alignment of said member. Instances of this struct are placed on the heap via malloc. Although I'm currently using static C code to determine the padding size, I'm

On Feb 1, 2010, at 12:01 PM, Garrison Venn wrote: > Sorry as you interpreted I meant minimum alignment. > > My issue is in translating from a C struct which has a member aligned with > __attribute__((__aligned__)) to a generated packed StructType where I use padding > to force the alignment of said member. Instances of this struct are placed on the heap > via malloc. Although

I got bit by this in LLVM 2.4 DagCombiner.cpp and it's still in trunk: SDValue DAGCombiner::visitSTORE(SDNode *N) { [...] // If this is a store of a bit convert, store the input value if the // resultant store does not need a higher alignment than the original. if (Value.getOpcode() == ISD::BIT_CONVERT && !ST->isTruncatingStore() && ST->isUnindexed()) {

So I gather this means that malloc was removed from the IR because there are platforms that don't have non-stack allocation semantics? Garrison On Dec 7, 2009, at 12:21, Chris Lattner wrote: > > On Dec 7, 2009, at 8:45 AM, Garrison Venn wrote: > >> Ouch! Didn't see that. So at the risk of irritating those still in the process of baking 2.7, what is the sanction way of

On Dec 7, 2009, at 9:49 AM, Garrison Venn wrote: > So I gather this means that malloc was removed from the IR because > there are platforms that don't have non-stack allocation semantics? No, it was removed because it wasn't necessary, and the malloc 'instruction' didn't support 64-bit targets. -Chris > > Garrison > > On Dec 7, 2009, at 12:21, Chris

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().

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

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 =

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 (working copy) @@ -4903,9 +4903,9 @@ // resultant store does not need a higher alignment than

Ouch! Didn't see that. So at the risk of irritating those still in the process of baking 2.7, what is the sanction way of doing heap allocation going forward? :-) Garrison On Dec 7, 2009, at 11:18, Chris Lattner wrote: > > On Dec 7, 2009, at 2:13 AM, Florian Merz wrote: > >> Hi everyone, >> >> I noticed that MallocInst and FreeInst have been removed from the

On Monday 07 December 2009 17:55:44 Chris Lattner wrote: > On Dec 7, 2009, at 9:49 AM, Garrison Venn wrote: > > So I gather this means that malloc was removed from the IR because > > there are platforms that don't have non-stack allocation semantics? > > No, it was removed because it wasn't necessary, and the malloc > 'instruction' didn't support 64-bit

Sorry, these IRBuilder methods are really in IRBuilderBase. Garrison On Jul 11, 2011, at 11:54, Garrison Venn wrote: > Are the get type methods for IRBuilder, such as const IntegerType *getInt32Ty(), going to have > their return type const qualifiers removed? Doing so would match the semi equivalent static > methods of Type, such as static IntegerType *getInt32Ty(LLVMContext &C).

Ok, I've isolated the recent additions that cause the issue and supplied a patch which is NOT meant to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) The patch is offset from HEAD. The patch is a hack which removes use of the MCSymbol::isDefined(...) method, as its use happens to break in the exception JIT context; both in

Ok thanks I'll try that. I was trying to avoid re-building llvm-gcc. Garrison On Dec 10, 2010, at 12:12, Bob Wilson wrote: > > On Dec 10, 2010, at 6:11 AM, Garrison Venn wrote: > >> Hey Chris, >> >> Ok, so I'm working on creating this trivial patch, for starters, but I'm trying to identify >> a controlled unit test for tblgen. So all of the

Attached is a patch for the non ExceptionDemo demos which gets rid of the old const qualifier usage for Type. Although I recently commited the ExceptionDemo changes, I did not want to touch code that I did not "own" without other's approval. Even though trivial, I did not test this patch. Garrison -------------- next part -------------- A non-text attachment was scrubbed... Name:

I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed before any unwind happens. -- James 2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > No, there is no magic. :-) > > To me though, the tools are magic, because I have no clue what they are > doing without looking at them and using them. >

On Dec 7, 2009, at 8:45 AM, Garrison Venn wrote: > Ouch! Didn't see that. So at the risk of irritating those still in > the process of baking 2.7, what is the sanction way of doing heap > allocation going forward? :-) No, we only support stack allocation in LLVM IR now. :-) You can call out to normal malloc and free, just like any external function. -Chris > >

Hi Garrison, Does r101453 fix this? -Chris On Mar 22, 2010, at 12:35 PM, Garrison Venn wrote: > Ok, I've isolated the recent additions that cause the issue and supplied a patch which is NOT meant > to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) > The patch is offset from HEAD. > > The patch is a hack which

Hi Chris, Thanks for the review! I believe I caught most of the syntax style issues with the attached patch. It only contains these style changes. On Dec 12, 2010, at 19:30, Chris Lattner wrote: > > On Dec 12, 2010, at 10:54 AM, Garrison Venn wrote: > >> >> Hey Chris, >> >> The following patch removes all global references to a RecordKeeper instance for the