similar to: [LLVMdev] LegalizeIntegerType and truncating stores

Hi Mon Ping, > In PromoteIntOp_STORE, why can we not promote a value and generate a > truncating store if the incoming store is a truncating store? as far as I can see you can just remove the assertion. Ciao, Duncan.

Hi, Our target only has native support for i32 and f32 types. For data types smaller than these, I have to custom lowering truncating store using two atomic load instruction (which have the same semantics as ISD::ATOMIC_LOAD_AND and ATOMIC_LOAD_OR, respectively). I run into a problem during the legalization process, where the legalizer complains that ISD::STORE and ISD::ATOMIC_LOAD_OR (generated

Problem solved by returning the second result of the ATOMIC_LOAD_OR node... On Wed, May 30, 2012 at 9:38 PM, Lei Mou <lei.mou.uu at gmail.com> wrote: > Hi, > > Our target only has native support for i32 and f32 types. For data > types smaller than these, I have to custom lowering truncating store > using two atomic load instruction (which have the same semantics as >

Hi Lei, Le 31/05/2012 03:44, Lei Mou a écrit : > Problem solved by returning the second result of the ATOMIC_LOAD_OR node... You got the chain instead of the loaded value. IMHO, a better solution would have been to add a Pat<> rule to match truncstores and expand them into target store/load/and/or. Pat : <(truncstore16 GPR:$val, MEM:$mem), (store MEM:$mem, (or

In LegalizeDAG.cpp, truncating stores are custom-lowered in line 1314-1317: 1314 case TargetLowering::Custom: 1315 ReplaceNode(SDValue(Node, 0), 1316 TLI.LowerOperation(SDValue(Node, 0), DAG)); 1317 break; Is there a reason it doesn't check whether the SDValue returned from TargetLowering::LowerOperation is null before it replaces the

Hi, I am working on C/C++ language support for the Armv8.2-A half-precision instructions. I've added support for _Float16 as a new source language type to Clang. _Float16 is a C11 extension type for which arithmetic is well defined, as opposed to e.g. __fp16 which is a storage-only type. I then fixed up the AArch64 backend, which was mostly straightforward: this involved making operations

Hi Akira, On 01/06/12 02:27, Hatanaka, Akira wrote: > In LegalizeDAG.cpp, truncating stores are custom-lowered in line 1314-1317: > > 1314 case TargetLowering::Custom: > 1315 ReplaceNode(SDValue(Node, 0), > 1316 TLI.LowerOperation(SDValue(Node, 0), DAG)); > 1317 break; > > Is there a reason it doesn't check whether the

I'm working on defining the instructions and implementing the lowering code for a Z80 backend. For now, the backend supports only the native CPU-supported datatypes, which are 8 and 16 bits wide (i.e. no 32 bit long, float, ... yet). So far, a lot of the simple stuff like immediate loads and return values is very straightforward, but now I got stuck with ISD::TRUNCATE, as in:

Hi, I am trying to get llvm working for an architecture that has 64bit registers, but 32bit addresses. Because of that, I want the pointers to also be 32bit, although they will live in a 64 bit register. On the frontend, I do not encounter any issues, but when I provide a ... "p:32:32:32" ... DataLayout specification to the backend, things get ugly: - SelectionDag is producing a

For example, truncating store of an i32 to i6. My assumption was that this should write the low six bits of the i32 to somewhere in memory. Should the top 24 bits of a corresponding 32 bit region of memory be unchanged, zero, undefined? Should the two bits that would round the i6 up to a byte be preserved, zero, undefined? I can't write six bits directly so am trying to determine what set

OK, I'm clear on scalars. Data races are thankfully OK in this context. Densely packing vectors sounds efficient and is clear in the case where lanes * width is a multiple of 8 bits. I don't think I understand how it works in other cases. If we could take store <4 x i8> truncating to <4 x i7> as an example. This can be converted into four scalar i8 -> i7 stores with

If v4i8 is a legal type then getTypeToPromoteTo should return the pair v4i8 and 'legal'. This looks like the root of the problem. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 22:10 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> v4i8 itself is a legal type, just not

Hi, I'm working on an LLVM backend for an architecture which does not natively support half-word loads. I'm having trouble getting LLVM to promote i16 to i32 loads for me - should I expect LLVM to be able to do this, are do I have to write a custom lowerer? This post (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/019929.html) gave me the impression that it should be possible,

v4i8 itself is a legal type, just not on the 'AND' operation. So there seems to be multiple problems here. 1) PromoteVectorOp doesn't handle the case where the types are not the same size, this occurs because #2 2) getTypeToPromoteTo doesn't actual check to see if the type it should promote to makes any sense. 3) PromoteVectorOp also doesn't handle the case where

I am trying to convert a string to a double using "as.numeric" However, R is truncating the results! Options(digits) is set to 7. Can anyone shed some light on this? Thanks! > b[1] [1] "116.28125" > summary(b[1]) Length Class Mode 1 character character > c <- as.numeric(b[1]) > c [1] 116.2812 -- View this message in context:

Notice that PromoteVectorOp is called after the type legalization legalized all of the types in the program. It legalizes the *operations*, not the types. So, you should only see legal types (Legal types are types that fit into your registers). So, if your target has v2i32, I suspect that v4i8 is an illegal because it has a different size. -----Original Message----- From: Villmow, Micah

I want to promote i1 to i32 and not i16 as i32 is my native type and i16 is emulated, but I need to handle i16 as a special case so I don't want to promote it. I will see if what Bill pointed out is what I need. Micah -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, February 03, 2009 11:08 AM To:

Sorry, <4 x i8> should convert to a <1 x i32>. What currently is happening is that it is returning a <2 x i32> because <1 x i32> does not exist. Micah > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Monday, July 30, 2012 10:51 AM > To: Villmow, Micah; Developers Mailing List > Subject: RE: Vector promotion broken

Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT =

>Though I am having trouble in understanding how  x86 supports the <1 x i64> type. Based on looking at the code, it should fail because v1i64 is not supported on the x86 platform as >far as I can tell. The Type-Legalizer can handle vector types in the following ways: 1. Split - this splits vectors into two halves. For example on SSE4, <4 x i64> is split to <2 x i64> 2.