similar to: [LLVMdev] getelementptr on static const struct

> you can't, you can only get a ConstantAggregateZero.  This is actually kind of > annoying, and means that places expecting a ConstantArray have to remember to > also check for ConstantAggregateZero.  Perhaps there's a good reason for the > current design, but if not it would be great to eliminate this wart. Well, I think the main reason it so reduce the size of .ll / .bc when

Hi all. I propose to use wrapper for this kind of constant objects. Consider next code: Constant* C = reinterpret_cast<Constant*>(I->getOperand(idx)); Constant* ArrayItem; if (!isa<ConstantAggregateZero>(C)) ArrayItem = reinterpret_cast<Constant*>(I->getOperand(ArrItemIdx)); else ArrayItem = ZeroInt; Code analog within wrapper: ConstOrZero

Hi Anton, >> you can't, you can only get a ConstantAggregateZero. This is actually kind of >> annoying, and means that places expecting a ConstantArray have to remember to >> also check for ConstantAggregateZero. Perhaps there's a good reason for the >> current design, but if not it would be great to eliminate this wart. > Well, I think the main reason it so

Hi all. How to force the creation of arrays with zeroes? Or this use-case is not provided? -- Truly yours, Stepan Dyatkovskiy

Hi Tim, Thank you for your quick response. > I'm not convinced that's the best solution, at least conceptually. > SlotSize really is an unsigned quantity, and though it's unlikely we'd > like 0x80000000 to be interpreted as positive, rather than negative if > it ever does occur. I totally agree with you. I rewrote my fix and made a test case according to your

Hi Chris. There is no zero arrays created. Probably this patch is not optimal and I'll reworked it today. But the main idea is keep a single zero-item when ConstantAggregateZero was wrapped and return this zero item as result of getOperand call. Note that wrapper has no parent classes, it has very local and short lifetime (method body), it exists outside the LLVMContext and needed for

The Constants.cpp file returns a ConstantAggregateZero object when you pass it a c"\000" string. Here is the code: Constant *ConstantArray::get(const ArrayType *Ty, const std::vector<Constant*> &V) { // If this is an all-zero array, return a ConstantAggregateZero object if (!V.empty()) { Constant *C = V[0]; if (!C->isNullValue())

How many times will a typical client call getOperand on your helper when it wraps a 10,000 element ConstantAggregateZero? With CAZ the client is force to think about this case, and often handles it much much more efficiently. CAZ is a time optimization as well as a space optimization. -Chris On Jan 21, 2012, at 12:03 AM, Stepan Dyatkovskiy <STPWORLD at narod.ru> wrote: > Hi Chris.

Dear LLVM developers, I am a developer of SML#, an ML-style functional programming language developed at Tohoku University. Currently we are intending to use LLVM as the backend of our SML# compiler in our upcoming release, and have rewritten our frontend and runtime so that they can cooperate with LLVM. LLVM works extremely fine with our SML# compiler. We are grateful to LLVM community for

I'd really rather not do this. Faking that large zero filled array is represented with ConstantArray means that the compiler will inevitably end up calling getOperand on each of those elements, burning a ton of compile time. -Chris On Jan 20, 2012, at 12:16 PM, Stepan Dyatkovskiy <STPWORLD at narod.ru> wrote: > Hi all. I propose to use wrapper for this kind of constant objects.

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Steve King > Sent: 23 July 2015 01:45 > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] signext on function parameters and return. > > Hello, > For a simple function taking a short and returning a short, clang > generates IR with this function

Hi Chris, please read below: > In many cases that is true, but for indirect calls (calls through a > function pointer) it isn't. > > > All that is needed is to add some kind of sign attribute to the > > definition of callee function which will be set by the front-end and > > eventually saved in Function class. > > Sure. Adding an attribute is what we need

Hello, For a simple function taking a short and returning a short, clang generates IR with this function signature: define signext i16 @foo(i16 signext %x) Some questions please: 1) For the input parameter and return value, does the target control whether clang uses signext vs something else? If so, how does this target query work? 2) Does the presence of the signext mean it's imperative

Hi Stepan, > Hi all. How to force the creation of arrays with zeroes? Or this use-case is not provided? you can't, you can only get a ConstantAggregateZero. This is actually kind of annoying, and means that places expecting a ConstantArray have to remember to also check for ConstantAggregateZero. Perhaps there's a good reason for the current design, but if not it would be great to

On May 27, 2008, at 3:33 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com > wrote: > Chris, > I see, so in deed the front-end sets the attributes on the declaration > of the called function; which in theory is also available to the > caller > through the CALL node. Right. > Now here is what I think: > I agree that 4 attributes are

Hello,everyone: I want to known how to let clang compile my local array to local variables: I have the code : int main() { int a[3]={1,2,3}; int b=7; int c=8; int d=9; int e=10; int f=11; test(b,c,d,e,f,a); return 0; } I use clang command:clang --target=mipsel -emit-llvm -S a.c -o a.ll The a.ll is: @main.a = private unnamed_addr constant [3 x i32] [i32 1, i32 2, i32 3],

Hi all, I am newbie for llvm. I just create a global variable, there are some statements in my pass like: LoadInst* int64_64 = new LoadInst(pthreadPID, "", false, OptAplusOne); int64_64->setAlignment(8); int64_64->dump(); LoadInst* int32_65 = new LoadInst(gvar_int32_myFlag, "", false, OptAplusOne); int32_65->setAlignment(4);

On May 28, 2008, at 11:53 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com > wrote: >> Ok. We already have this, with the 'signext' attribute. This code: >> >> signed char g(); >> signed char foo(){ >> return g(); >> } >> >> compiles into: >> >> define i8 @foo() signext nounwind {

Hi Kit, I see you have been working on IPRA (https://reviews.llvm.org/D45308), and would therefore like to bring up an issue with it I am looking into on SystemZ (see https://reviews.llvm.org/D46232). I first realized that %r14, the return register, must be saved and restored with IPRA enabled, since otherwise the function can't return. This is a callee saved register so without IPRA

Hi, While comparing the code by LLVM and GCC for some major libraries, I found that LLVM fails to apply jump threading with a method whose return type is std::pair<int, bool> (actually, any pair of 32-bit values like std::pair<bool, int> and std::pair<int, int>). For example, jump threading does not work for the if statement in func. std::pair<int, bool> callee(int v) {