similar to: [LLVMdev] Address calculation

I have ran across a case where the function isIdenticalTo is return true for instructions that are not equivalent. The instructions in question are load/store instructions, and is causing a problem with MachineBranchFolding. The problem is this, I have two branches of a switch statement that are identical, except for the size of the store. Here is some cut-down LLVM-IR to showcase the issue:

On Jan 4, 2011, at 11:08 AM, Villmow, Micah wrote: > I have ran across a case where the function isIdenticalTo is return true for instructions that are not equivalent. The instructions in question are load/store instructions, and is causing a problem with MachineBranchFolding. The problem is this, I have two branches of a switch statement that are identical, except for the size of the store.

I have the following function: define void @test_fc_0_kernel(i16 signext %x, i16 signext %y, i16 addrspace(11)* %input, i32 addrspace(11)* %result) { entry: %call = tail call i32 @get_id(i32 0) ; <i32> [#uses=2] %cmp = icmp slt i16 %x, %y ; <i1> [#uses=1] br i1 %cmp, label %if.then, label %if.end

I am getting an assert on a bad legalization. Assertion failed: Result.getValueType() == Op.getValueType() && "Bad legalization!", file ..\..\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp, line 3976 Can someone explain to me what this means in term of backend code generation, how it might be occurring, and possible ways to fix this? I don't see how the value type of an

Mon Ping, Thanks for the tip, but I can't for the life of me seem to get the Value from a StoreSDNode. From looking at the SelectionDAGNodes header file, the only class that has the getValue function call is SrcValueSDNode that returns a Value type. The only class that has getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode is what I want and when I try to cast the

How do I access the address qualifier from the store instruction. Given the following code: define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) nounwind { entry: %neg = sub float -0.000000e+000, %x ; <float> [#uses=1] store float %neg, float addrspace(11)* %result ret void } When I attempt to generate this code, I'm

On Mon, Dec 6, 2010 at 6:16 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Peter Collingbourne >> Sent: Monday, December 06, 2010 2:56 PM >> To: David Neto >> Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu >>

Hi Micah, all, On Dec 13, 2011, at 8:49 AM, Villmow, Micah wrote: If you look at the test cases, you can infer what needs to be done. Basically since this is targeted for OpenCL, we annotate OpenCL kernels slightly different than normal functions and that is what causes the code to be generated. That being said, on my list of things to do is fix this so that any function will be generated

I have a simple program that generates correct intermediate representation. However, when working on my backend, and my lowering function gets called. The comparison operation is flipped via an invalid transformation. i.e. gt ==> le, lt ==> ge etc.. define void @test_fc_if_gt(double %x, double %y, double addrspace(11)* %result) { entry: %x.addr = alloca double ;

The address qualifier is stored in the type of %result. From that operand, you can get the Value and then call getType. The type for result should be a PointerType which you cast to a PointerType and get the getAddressSpace e.g. cast<PointerType>(Ty)->getAddressSpace() -- Mon Ping On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > How do I access the address qualifier

> -----Original Message----- > From: Michele Scandale [mailto:michele.scandale at gmail.com] > Sent: Saturday, August 10, 2013 6:29 AM > To: Micah Villmow > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > On 08/10/2013 02:47 PM, Micah Villmow wrote: > > Michele, > > The information you are trying to gather is fundamentally

So, I have this small test program that I figured would cause no problems but want to test all the various data types and operations with my modified sparc backend. I've been working on LLVM for about 3 days now, so this might be a problem with not knowing enough yet, so thanks for bearing with me. The code that I based my example off of is compiled to LLVM-IR from: void

On Sep 15, 2008, at 3:05 PM, Villmow, Micah wrote: > I am getting an assert on a bad legalization. > Assertion failed: Result.getValueType() == Op.getValueType() && "Bad > legalization!", file ..\..\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp, > line 3976 > When you run into issues like this, it helps if you provide a bit more information. Please dump out

On Fri, Aug 24, 2012 at 4:07 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Villmow, Micah >> Sent: Friday, August 24, 2012 2:56 PM >> To: 'Eli Friedman' >> Cc: LLVM Developers Mailing List >> Subject: RE: [LLVMdev] RFC: Supporting different sized address space >> arithmetic >>

Mon Ping Wang wrote: > > On Sep 7, 2012, at 11:10 PM, Nick Lewycky<nicholas at mxc.ca> wrote: > >> Mon Ping Wang wrote: >>> Hi, >>> >>> I don't think we should make bit casts between pointers with different >>> address spaces illegal. Address spaces are not required to be disjoint. >>> In the N1169 spec, it says >>> A

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, September 10, 2008 3:30 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg On Wed, Sep 10, 2008 at 2:35 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Generating the following LLVM IR: > > define

On Mon, Oct 6, 2008 at 9:03 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I am attempting to get indexing code generation working with my backend. > However, it seems that the addresses being calculated is being multiplied by > the width of the data type. That's how most normal architectures/address spaces work. Is there something unusual about address space 11 in

On Sep 8, 2012, at 12:21 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Mon Ping Wang wrote: >> >> On Sep 7, 2012, at 11:10 PM, Nick Lewycky<nicholas at mxc.ca> wrote: >> >>> Mon Ping Wang wrote: >>>> Hi, >>>> >>>> I don't think we should make bit casts between pointers with different >>>> address

From: Villmow, Micah Sent: Tuesday, September 11, 2012 12:51 PM To: llvm-commits at cs.uiuc.edu Subject: Proposal: New IR instruction for casting between address spaces Problem: Bit casting between pointers of different address spaces only works if all address space pointers are the same size. With changes from email chain [1][2], support for different pointer sizes breaks the bitcast instruction

Hi, I've prepared patches for both LLVM and Clang to change the datalayout for R600. This may seem like a bold move, but I think it is warranted. R600/SI is a strange architecture in that it uses 64bit pointers but does not support 64 bit arithmetic except for load/store operations that roughly map onto getelementptr. The current datalayout for r600 includes n32:64, which is odd