similar to: [LLVMdev] PTX backend fails instruction selection for load of sext

On Mon, Oct 6, 2008 at 9:30 AM, Le Anh Quang <anh_quang.le at mailbox.tu-dresden.de> wrote: > Hi, > I have a question about the "sext..to" instruction. In the document, I found > two examples: > %x = sext i8 -1 to i16 > It means: > i8 -1 = 1111 1111 --> 1111 1111 1111 1111 = i16 > how can it determinate, that the i16 value %x positive is (65535)? > And

> I'm not sure about it, when sext to results a positve/negative value? sext does signed-extension, zext does unsigned-extension. This means that zext always extends by zero bits, while with sext the additional bits are all copies of the top bit of the original value. So with sext, if it was negative in the original type when considered as a signed value, then it will be negative in the

Hi Le Anh, > how can it determinate, that the i16 value %x positive is (65535)? > And the second example: I guess you should read up on the "two's complement" format, which is how a signed value is stored in most architectures (and in these examples). In short, a sext operation takes the highest bit of the original number (the sign bit) and copies it into all the higher

I saw the description in llvm documenattion for sext is as the following : -- sext (CST to TYPE) Sign extend a constant to another type. The bit size of CST must be smaller or equal to the bit size of TYPE. Both types must be integers. But in the code of llvm-2.6, the judge condition just allow smaller to the bit size of TYPE as the following : case Instruction::SExt: return

On Jun 20, 2013, at 4:39 PM, Bin Tzeng <bintzeng at gmail.com> wrote: > Hi all, > > There might be a simple error in the LLVM reference manual. The example for sext instruction: > > %X = sext i8 -1 to i16 ; yields i16 :65535 > > %X should yield i16: -1, as opposed to 65535. > Here is the simple patch (also attached): These are the same value. -Chris >

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bin Tzeng > Subject: Re: [LLVMdev] Error in the example of sext instruction in reference manual > Just for a little more clarity, is i16, i32... signed, unsigned, or > just a bit pattern? It's just a bit pattern. The operations performed on it can treat it as signed, unsigned, or

I have a CopyToReg that is copying from different size types, what's the best way to change that to a zext or sext node based on signed or unsigned? I'm fairly unfamiliar with SelectionDAG process (outside of the docs on llvm website). It seems like I should be able to insert a custom hook using the register class to identify the type, potentially in ISelDAGToDag.cpp or is there a better

Hi, I have a question about the "sext..to" instruction. In the document, I found two examples: %x = sext i8 -1 to i16 It means: i8 -1 = 1111 1111 --> 1111 1111 1111 1111 = i16 how can it determinate, that the i16 value %x positive is (65535)? And the second example: %y = sext i1 true to i32 1 --> 1111 1111 1111 1111 1111 1111 1111 1111 In this example, %y is -1 I'm not sure

Hi everybody, I am testing the PTX backend using the OpenCL NVIDIA SDK benchmarks. Compiling the Histogram64.cl program I get a several backend errors. I isolated one of them in the following kernel program: __kernel void kernel_function(__global int *input) { __local char localArray[16]; for(unsigned int index = 0; index < 16; ++index) localArray[index] = 0; input[0] =

Thanks for the reply. Just for a little more clarity, is i16, i32... signed, unsigned, or just a bit pattern? On Thu, Jun 20, 2013 at 9:17 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 20, 2013, at 4:39 PM, Bin Tzeng <bintzeng at gmail.com> wrote: > > > Hi all, > > > > There might be a simple error in the LLVM reference manual. The example

Hi all, There might be a simple error in the LLVM reference manual. The example for sext instruction: %X = sext i8 -1 to i16 ; yields i16 :65535 %X should yield i16: -1, as opposed to 65535. Here is the simple patch (also attached): Index: docs/LangRef.rst =================================================================== --- docs/LangRef.rst (revision 184496) +++ docs/LangRef.rst

I'm working on a Z80 backend and am trying to efficiently lower SEXT, specifically 8 to 16 bit, in LowerOperation() according to the following rules: The Z80 has 8 bit registers and 16 bit registers, which are aliased versions of two 8 bit registers. 8 bit registers are named A, H, L, D, E and some more. 16 bit registers are HL (composed of H + L), DE (D + E) - and some more - with L and

Thanks for getting back to me. So those nodes record if the type has already been expanded from a narrower type. Can you elaborate how I could use these to help? Again, I'm pretty unfamiliar with the SDNodes. Thanks. On Tue, Jan 27, 2015 at 3:22 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 01/27/2015 12:16 PM, Ryan Taylor wrote: > > I have a CopyToReg that

Hi everyone, I've been using SCEV Delinearization but it fails when other-than-pointer-size values are used in the subscripts. To make that clear, say that we have a target in which pointers are 64-bit for (int32_t i ...) for (int32_t j ...) a[i][j] = ... doesn't work while this: for (int64_t i ...) for (int64_t j ...) does work. I assume that the former does not work because

Dear LLVM NVPTX maintainers, Just to have the issue recorded, I don't know how important it is: clang generates linkonce_odr out of __inline__, and NVPTX generates .weak out of linkonce_odr (how it happens - a big question, btw, because I can't find anything related in NVPTX asm printer - does it chain to some other printer?), and finally ptxas (both 4.2 and 5) fails to compile it to

Hi, Looks like "{" and "}" are lost when trying to use the combination of Clang and NVPTX, which may result into clash of definitions of the function-scope and asm-scope. Here is an example: > cat test.cu __attribute__((device)) __attribute__((nv_linkonce_odr)) __inline__ int __any(int a) { int result; asm __volatile__ ("{ \n\t" ".reg .pred

For void test0(unsigned short a, unsigned short * in, unsigned short * out) { for (unsigned short w = 1; w < a - 1; w++) //this will never overflow out[w] = in[w+7] * 2; } I think it will be sufficient to add a couple of new cases to ScalarEvolution::HowManyLessThans -- zext(A) ult zext(B) == A ult B sext(A) slt sext(B) == A slt B Currently it bails out if it sees a non-add

Hi, This is somewhat similar to the previous thread regarding missed vectorization opportunities (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084765.html), but maybe different enough to require a new thread. I'm seeing some missed vectorization opportunities in the loop vectorizer because SCEV is not able to fold sext/zext expressions into recurrence expressions (AddRecExpr). This

Hi Michael, Thanks for the reply. I've seen but have not used it. FWIW, the problem is not how to generate the runtime checks (although it'd be good if we can get it for free), but how to clean up the SCEVs. Does PSE do that ? Cheers, Stefanos Στις Δευ, 21 Σεπ 2020 στις 11:59 π.μ., ο/η Michael Kruse < llvmdev at meinersbur.de> έγραψε: > Have you looked into

I have a CopyToReg that is moving a 16bit reg to a 32bit reg, it's currently being mapped out as a simple mov (not an ext), I would like to change that to an ext. It seemed that the SelDAG was the easiest and cleanest way to do this. I can change the mov to an extension MI in the .td file; however, I can't tell at that point whether it's a sext or a zext, so it seemed the SelDAG was