search for: getsextortrunc

Displaying 10 results from an estimated 10 matches for "getsextortrunc".

2014 Jul 08
2
[LLVMdev] LLVM commit 410f38e01597120b41e406ec1cea69127463f9e5
2014-07-08 12:11 GMT-07:00 Matt Arsenault <Matthew.Arsenault at amd.com>: > On 07/07/2014 09:47 PM, deadal nix wrote: > > OK from what I understand, the DAG.getSExtOrTrunc(SetCC, DL, SelectVT) > is unecessary and the SelectVT is nto the right type (as it is called with > incorrect parameter). > > Here is a patch so it won't generate a loop. I ran make check and it > doesn't look like anything is broken. > > No, it is necessary and is the...
2014 Jul 08
2
[LLVMdev] LLVM commit 410f38e01597120b41e406ec1cea69127463f9e5
OK from what I understand, the DAG.getSExtOrTrunc(SetCC, DL, SelectVT) is unecessary and the SelectVT is nto the right type (as it is called with incorrect parameter). Here is a patch so it won't generate a loop. I ran make check and it doesn't look like anything is broken. 2014-07-07 11:36 GMT-07:00 Matt Arsenault <arsenm2 at gmail....
2014 Jul 06
2
[LLVMdev] LLVM commit 410f38e01597120b41e406ec1cea69127463f9e5
OK, so in you case, you want DAG.getSExtOrTrunc(SetCC, DL, SelectVT) to tunc the result from i64 to i32 on 64 bits targets, if I understand correctly. 2 questions: - Why not generating a selectcc node directly ? It avoid having to mess up with intermediate values. - Why calling getSetCCResultType(VT) ? VT is not the type of a parameter of set...
2014 Jul 05
2
[LLVMdev] LLVM commit 410f38e01597120b41e406ec1cea69127463f9e5
Hi, I'm working on a target which have a variable size for CC (the same size as the arguments). As a result getSetCCResultType, return a variable size. In this commit, at the line DAG.getSExtOrTrunc(SetCC, DL, SelectVT), on my target, you end up generating the Node you are replacing, and so creating a loop in the DAG, which give a whole new meaning to the A in the acronym. Subsequent code manipulating the DAG to not like it at all. Can you explain me what you were trying to do in that commit...
2012 Aug 25
0
[LLVMdev] FW: RFC: Supporting different sized address space arithmetic
...EVT NewPtrVT = TLI.getPointerTy(dyn_cast<PointerType>( + SV->getType())->getAddressSpace()); + if (PtrVT != NewPtrVT) { + // Check to see if we want to change the size of the pointer + // based on the address space and if so extend or truncate the pointer. + Ptr = DAG.getSExtOrTrunc(Ptr, getCurDebugLoc(), NewPtrVT); + PtrVT = NewPtrVT; + } This situation should be impossible: you're checking whether a pointer has the same type as itself. If you're hitting this, it's just a symptom of a bug elsewhere. The same applies to other places you perform this sort of...
2012 Aug 24
5
[LLVMdev] FW: RFC: Supporting different sized address space arithmetic
> -----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 > > Eli, > There is a patch that implements the beginning what I think is the > correct approach to support the backend
2012 Aug 27
2
[LLVMdev] FW: RFC: Supporting different sized address space arithmetic
Most likely this code was added before getSExtOrTruncate was added, but not 100% sure. It seems to assume that no pointer can be more than 64bits in size. > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Friday, August 24, 2012 4:27 PM > To: Villmow, Micah > Cc: LLVM Developers Mail > Subject: Re:...
2012 Aug 27
0
[LLVMdev] FW: RFC: Supporting different sized address space arithmetic
On Mon, 27 Aug 2012 15:25:50 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Most likely this code was added before getSExtOrTruncate was added, > but not 100% sure. It seems to assume that no pointer can be more > than 64bits in size. Does LLVM generally support pointers of greater than 64 bits? -Hal > > > -----Original Message----- > > From: Hal Finkel [mailto:hfinkel at anl.gov] > > Sent: Fri...
2012 Aug 30
2
[LLVMdev] FW: RFC: Supporting different sized address space arithmetic
...rTy(dyn_cast<PointerType>( > + SV->getType())->getAddressSpace()); > + if (PtrVT != NewPtrVT) { > + // Check to see if we want to change the size of the pointer > + // based on the address space and if so extend or truncate the > pointer. > + Ptr = DAG.getSExtOrTrunc(Ptr, getCurDebugLoc(), NewPtrVT); > + PtrVT = NewPtrVT; > + } > > This situation should be impossible: you're checking whether a pointer > has the same type as itself. If you're hitting this, it's just a > symptom of a bug elsewhere. The same applies to other pl...
2012 Aug 24
0
[LLVMdev] FW: RFC: Supporting different sized address space arithmetic
Micah, There are a number of variable names in this patch that don't follow the naming convention (which specifies that they should start with an uppercase letter). > if (PtrBits < 64) > - OffsVal = DAG.getNode(ISD::TRUNCATE, getCurDebugLoc(), > - TLI.getPointerTy(), > + OffsVal = DAG.getNode(ISD::TRUNCATE,