similar to: [LLVMdev] i64 type in optimizer

Thanks for the answer.. A followup question - Is this already taken into consideration when generating address calculation offset etc or would this need to be specially taken care? I am assuming all load/stores also would need to be custom lowered. thanks dz On Wed, Dec 29, 2010 at 5:45 AM, Bill Wendling <wendling at apple.com> wrote: > On Dec 28, 2010, at 4:02 PM, drizzle drizzle

Hi Is there a way to enforce a different alignment on vales on stack as compared to other basic types. Particularly, i would like characters to be stored at 2 byte boundary. thanks dz

I apologize if this is the wrong list. I'm writing a language and outputting llvm-ir instead of using the c api. I looked at clang's output a few times but I'm a little unsure what to do in this case As an example I have a function called itoa which takes an int and returns a string. Strings in my language has 2 fields, the pointer and byte length. On a 64bit machine it'd be

Hi Any ideas on how I can represent readonly registers? I do not want any register allocation/liveness analysis to happen for these. thanks dz

Hi is there a way to know later that an earlier pass inside the codegen might have eliminated a virtual register. I carry information abt virtual registers which i would like to update if any virtual register does not exist since. thanks dz

The LRM (http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic) essentially states that: - ptr is dead before a call to "lifetime.start size, ptr" - ptr is dead after a call to "lifetime.end size, ptr" This is all good and fine, and the expected use case is that all "lifetime.end size, ptr" markers are matched with a preceding "lifetime.start

> (Right?) Uh no, the register content explicitly does change :( We insert REV instructions (byteswap) on each bitcast. Bitcasts can be merged and elided etc, but conceptually there's a register content change on every bitcast. James On Wed, 13 Jan 2016 at 18:09 Philip Reames <listmail at philipreames.com> wrote: > > > On 01/13/2016 08:01 AM, Hal Finkel via llvm-dev

> Ok. Then we need to change the LangRef as suggested. Given this is a rather important semantic change, I think you need to send a top level RFC to the list. FWIW, I don't think this is a semantic change to LLVM-IR itself. I think it's more clearing up the misconception that LLVM-IR semantics also apply to SelectionDAG's operations. That said, I do think it's important to

This explanation makes a lot more sense to me. I think it would make sense to document this mental model, but I agree that this interpretation does not seem to require changes to the IR semantics. Just to check, this implies that DSE *is* legal right? Philip On 01/14/2016 05:48 AM, James Molloy wrote: > Hi, > > I've given a bit of misinformation here and have caused some >

Hi, > "It is always a no-op cast because no bits change with this conversion. The conversion is done as if the value had been stored to memory and read back as type ty2." I think a simple "as-if" in there should be sufficient; "It is always a no-op cast because it acts as if no bits change with this conversion. The conversion is done as if the value had been stored

[resending so the message is smaller] ----- Original Message ----- From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> To: "Quentin Colombet" <qcolombet at apple.com> Cc: "llvm-dev" <llvm-dev at lists.llvm.org> Sent: Wednesday, January 13, 2016 2:35:32 AM Subject: Re: [llvm-dev] [GlobalISel] A Proposal for global instruction

----- Original Message ----- > From: "James Molloy" <james at jamesmolloy.co.uk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Quentin Colombet" <qcolombet at apple.com> > Sent: Wednesday, January 13, 2016 9:54:26 AM > Subject: Re: [llvm-dev] [GlobalISel] A Proposal for global

Hi As I understand live variable analysis will set the def/kill properties of operands. In that case, is it still needed to set the kill flags when possible during lowering? thanks dz

I have a question about when we should apply these pointer aliasing rules. Do the rules tell us when a load/store is safe? "Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior is undefined." So this means the conversion discussed here is still safe in terms of memory safety, but its meaning after conversion

To create a stack based (local) 64 bit integer in LLVM IR, I used: Value *var = builder.CreateAlloca(Type::getInt64Ty(Ctx)); I wish to pass this variable to a function "void foo(unsigned long)". I created the signature of function foo() as follows: Constant *func = M->getOrInsertFunction("foo", Type::getVoidTy(Ctx),Type::getInt64Ty(Ctx), NULL); To pass the newly created

Hello, everyone, I encounter a strange problem about llvm type i64 and C++ type int64_t. I instrumented a program to call the function 'myFunction' in the C++ shared library. 'myFunction' is something like this: int64_t myFunction() { int64_t retValue; ... std::cout << "retValue: " << retValue << "\n"; return retValue; }

How do I tell the optimizer that the (dereferenced) value of an i8** parameter is NULL at the start so that it can eliminate the check? I have code like: void test2(void** ex) { printf("go\n"); // does not change *ex } void call2(void** ex); void testeh(void** ex) { // I want to tell the optimizer *ex is null so it can eliminate the first

On 4/4/2011 6:45 PM, Eli Friedman wrote: > On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> wrote: >> >>> Hi, >>> Is it correct to convert, >>> %196 = load i32* %195, align 8 ;<i32> [#uses=1] >>> %197 = zext i32 %196 to i64 ;<i64> [#uses=1] >>> %198 =

On 07/09/10 14:22, Erik de Castro Lopo wrote: [...] > When generating 32 bit code the struct looks like: > > <{ i32, pointer }> > > and for 64 bit code: > > <{ union { i32, i64 }, pointer }> Surely LLVM will cause the first structure to be correctly aligned on 64-bit platforms by automatically inserting padding? Is explicit alignment by the user

Consider writes to a struct {i32 a; i32 b}; The optimizer can currently combine stores (i32, i32) to a single i64 store operation. Is there a way to disable that? I feel that such optimizations may not result in any gain for PIC16 as PIC16 does everything on i8. - Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: