similar to: [LLVMdev] memory access optimizations

Please test if r115571 has fixed it. Evan On Oct 4, 2010, at 5:00 AM, Heikki Kultala wrote: > Bill Wendling wrote: >> On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: >> >>> Bill Wendling wrote: >>>> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >>>> >>>>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote:

Bill Wendling wrote: > On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > >> Bill Wendling wrote: >>> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >>> >>>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>>> >>>>> Our architecture has 1-bit boolean predicate registers. >>>>> >>>>> I've

I went ahead and implemented the allocation based on the maximum size of all structs seen so far... The problem is, the TargetData object from ExecutionEngine gives me a size of 12 for a struct containing a pointer and an i64 (on a 32-bit machine). However, the generated code seems to assume an alignment of 8, and tries to read the i64 value at offset 8, which obviously reads an invalid value.

Hi Yuanfang, > just a quick question, in llvm::TargetData, > > uint64_t MemberOffsets[1]; // variable sized array! > > MemberOffsets has two elements, why it's variable sized ? when a StructLayout object is allocated (in TargetData::getStructLayout), extra memory is allocated, more than that given by the size of the type. The extra memory is interpreted as being part of the

In the TargetData class (available from you ExecutionEngine), you have some informations available (such as StructLayout...). On Thu, Jun 18, 2009 at 5:08 PM, Nyx <mcheva at cs.mcgill.ca> wrote: > > That sounds rather cumbersome, is there no simpler way to get the actual > size > of a struct? > > > John Criswell wrote: > > > > Nyx wrote: > >>

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 Dan, >Did the code in the tutorial work at some point? Offhand, I wouldn't expect >any of my recent changes to have affected this. I'm reluctant to fix this >without understanding how the original code was intended to work. The code works, but not as shown in the tutorial. In the tutorial, it shows that multiple calls to pure functions (sin, cos) can be optimized. Without the

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

On 02/11/10 22:48, Mark Leone wrote: > You can also use getelementptr to get the offset of a struct member: > > http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt Yup, except that this returns a constant expression in general, rather than a number. There's even a helper for doing this: ConstantExpr:getOffsetOf Ciao, Duncan. > > - Mark > > On

On Jul 8, 2009, at 11:16 AM, Won J Jeon wrote: > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I > have the following error message. > > CC arch/arm/kernel/traps.o > cc1: /home/wonjeon/llvm/lib/CodeGen/SelectionDAG/ > SelectionDAGBuild.cpp:5388: void > llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallSite): >

Last time I looked at the union stuff, I was trying to decide how to implement TargetData.cpp for unions, and whether or not to copy the way structs handled memory layout. Currently structs have an auxilliary data structure (StructLayout) that is used to cache the overall size of the struct and the offset of each member. In the case of unions, it doesn't need the offsets, since they are always

On 04/10/2014 09:02 PM, Krzysztof Parzyszek wrote: > On 4/10/2014 8:40 PM, Rodney M. Bates wrote: >> >> I could probably create llvm IR in this style by generating explicit >> address arithmetic, but I suspect that might hurt the optimization >> possibilities, perhaps a lot. It looks like re-raising the level to >> field numbers would not be horribly difficult,

> > At first I thought this could be handled when lowering > loads and stores, but I realize that I can only catch the > targeted addresses of loads/stores here - however address > calculation nodes may occur anywhere in a DAG. > > > > So my first impulse would be to adjust the constants when > the GEP instructions are transformed to ADDs. Afaics his > would mean

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

I have a question. If the size of long is 8 on your x64 platform. Because the size of long is so different on different platform, sad it is. 2009/9/23, David Greene <dag at cray.com>: > How are bitfields handled in StructLayout? In LLVM 2.5 the > struct is unambiguously size by: > > StructSize += TD.getTypePaddedSize(Ty); // Consume space for this data > > In LLVM 2.6

Thanks for the bug report. The attached file isn't helpful for reproducing the problem. I don't have all the header files that are included, so I can't just try to run it through my version of llvm-gcc and see what happens. At a minimum, please attach the preprocessed source file along with the complete llvm-gcc command line that you used to compile it. That would

Bug #4521 has been filed. traps.c has been also attached. Thanks, Won On Wed, Jul 8, 2009 at 1:38 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 8, 2009, at 11:16 AM, Won J Jeon wrote: > > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I have the > following error message. > > CC arch/arm/kernel/traps.o >

How are bitfields handled in StructLayout? In LLVM 2.5 the struct is unambiguously size by: StructSize += TD.getTypePaddedSize(Ty); // Consume space for this data In LLVM 2.6 it's getTypeAllocSize, which does the same thing. Unfortunately, this is not correct for bitfields. For example, LLVM reports this struct: typedef struct test1 { short f0 : 10; char f1 : 5; long f2 : 1;

traps.i has been attached. I used 'make CROSS_COMPILE=llvm-arm-' to compile the kernel with default configurations provided by kernel package If you need more information, please let me know. Thanks, Won On Wed, Jul 8, 2009 at 3:00 PM, Bob Wilson <bob.wilson at apple.com> wrote: > Thanks for the bug report. The attached file isn't helpful for > reproducing the problem.

Hello, I am working on a target with native 16-bit units addressing.So, for a a[1] reference a a+1 expression should be generated for an i16. I found this issue discussed before: >From gohman at apple.com Wed Apr 1 12:37:16 2009 From: gohman at apple.com (Dan Gohman) Date: Wed, 1 Apr 2009 10:37:16 -0700 Subject: [LLVMdev] adjust address calculus for an architecture that does not address