similar to: [LLVMdev] variable sized array

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

On Sun, Apr 18, 2010 at 4:36 AM, Eugene Toder <eltoder at gmail.com> wrote: > According to documentation Twines should be used only for temporary > values and not stored, so allocating the in heap sounds wrong. Yes, in general you should never be naming Twine directly, except in the case where you need to make a Twine for an integer. All other uses should be considered poor style, as

I need to generate variables like status1, status2, status3, ...... request1, request2, request3, ...... this is my code, other unrelated detail are eliminated. static int varNum; static const char *getVarNum() { ++varNum; std::stringstream ss; ss << varNum; std::string *varname = new std::string(ss.str()); return varname->c_str(); } const char *VarNum = getVarNum(); Twine *x1 = new

According to documentation Twines should be used only for temporary values and not stored, so allocating the in heap sounds wrong. I think all you need here is static int varNum; ++varNum; Instruction *sstatusInst = new AllocaInst(StatusTy, Twine("status") + Twine(varNum), entry_inst); Instruction *sreqInst = new AllocaInst(ReqTy, Twine("request") + Twine(varNum),

Hello folks, I want to compile some fortran code to IR, but llvm-gfortran 4.2-2.9 does compile my fortran code. gfortran 4.2.1 fail with the same error. but gfortran 4.4.6 and ifort compiles fine. Attached is the file causing error. Error message is m_List.F90: In function 'exporttostring_': m_List.F90:925: error: conversion to non-scalar type requested I wonder if there any way I can

Hi, how can i correctly calculate the size of a member of a struct (including alignment etc)? This doesn't work : const StructType *STy = cast<StructType>(Ty); for (StructType::element_iterator I = STy->element_begin(), E = STy->element_end(); I != E; ++I) { usigned size =I->get()->getScalarSizeInBits(); //often

On Tue, Jun 7, 2011 at 2:33 PM, Yuanfang Chen <tabloid.adroit at gmail.com> wrote: > Hello folks, > I want to compile some fortran code to IR, but llvm-gfortran 4.2-2.9 does > compile my fortran code. gfortran 4.2.1 fail with the same error. but > gfortran 4.4.6 and ifort compiles fine. Attached is the file causing > error. Error message is > m_List.F90: In function

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 >

LLVMers, I have a const StructType *StTy where I call TargetData->getStructLayout(const_cast<StructType*>(StTy))->getSizeInBits() but it continues to return 64 regardless of the actual size of the struct? I want the size of the structure in bits, including alignment padding for offset calculations, is this not the right function call? Thanks. -------------- next part

One thing I want to mention. I believe in the current legacy pass manager implementation only one MachineFunction ever exists at a time. It is deleted before the next MachineFunction is created. This is very important for memory usage. I think the MachineOutliner being in the pipeline may create an exception to this. I think the initial version of retpoline used a ModulePass and that had to be

On Wed, Jul 15, 2020 at 6:39 PM Chen, Yuanfang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Indeed, but there is a distinction about their position in the pipeline. We run opt & codegen pipeline separately, Why, though? Is there a reason why this inherently makes sense, or is it just a historical accident? At least to me it seems that it would make more sense to run all passes

> On Jul 15, 2020, at 12:28, Chen, Yuanfang <Yuanfang.Chen at sony.com> wrote: > > In codegen with NPM, I've made all codegen passes (IR or MIR pass) to be only driven by `llc`. Both due to the way NPM registering pass (on-demand&dynamic instead of static initialization in Legacy PM), and reduce the confusion about which tool (`llc` or `opt`) to test codegen IR passes. >

Dear all, I'm currently working on the automated program analysis tool AProVE (http://aprove.informatik.rwth-aachen.de/) and would like to use LLVM for analysis of C programs. I have the following example C program dealing with simple lists of integers: ------------ start C example ------------- #include<stdlib.h> struct list_el { int val; struct list_el * next; }; typedef

Hello, Can I define a named type ? %rt = {%rt} llvm-as can parse this definition without errors. JIT executes '%0 = alloca %rt' as allocating a memory with size 0. Because the llvm::TargetData::getTypeAllocSize accually returns 0 in this case. The function that calculates %rt's size is by the TargetData::getStructLayout, which calculates the a layout of %rt. It can only returns 0

Hi Matt, which analysis is this? ________________________________________ From: Matt Arsenault <whatmannerofburgeristhis at gmail.com> on behalf of Matt Arsenault <arsenm2 at gmail.com> Sent: Tuesday, July 21, 2020 12:02 PM To: Craig Topper Cc: Chen, Yuanfang; Nicolai Hähnle; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new pass

On 05/28/15 15:27, Yuanfang Chen wrote: > #define GET_BIT(lll) \ > // blah blah > > #define G(label1,label2) \ > { \ > // decent amount code \ > ... > while (1) { \ > GET_BIT(label2); \ > }; \ > } > > void f() { > if (..)

-Yuanfang > -----Original Message----- > From: Arthur Eubanks <aeubanks at google.com> > Sent: Monday, July 13, 2020 12:49 PM > To: Chen, Yuanfang <Yuanfang.Chen at sony.com> > Cc: LLVM Developers' List <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by > new pass manager > > While we're

On Thu, Nov 11, 2010 at 12:11 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 11, 2010, at 8:45 AM, Jianzhou Zhao wrote: > >> Hello, >> >> Can I define a named type ?   %rt = {%rt} >> llvm-as can parse this definition without errors. >> >> JIT executes '%0 = alloca %rt' as allocating a memory with size 0. >> Because the

Hello guys, Do we have a pass to do unconditional branch folding except the one in Codegen? I checked in the lib/Transforms/Scalar, did not see any promising one. thank you, yuanfang

#define GET_BIT(lll) \ // blah blah #define G(label1,label2) \ { \ // decent amount code \ ... while (1) { \ GET_BIT(label2); \ }; \ } void f() { if (..) G('c', 'd'); while ( .. ) G('a','b'); } After perf sampling, a lot