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,