similar to: What should a truncating store do?

On 9/15/2017 5:49 AM, Jon Chesterfield via llvm-dev wrote: > 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? Unchanged. > Should the two bits that would round the i6 up to a byte

On 09/15/2017 10:55 AM, Friedman, Eli via llvm-dev wrote: > On 9/15/2017 5:49 AM, Jon Chesterfield via llvm-dev wrote: >> 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? > >

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

They are starting to look complicated. The patch linked is interesting, perhaps v1 vectors are special cased. It shouldn't be too onerous to work out what one or two in tree back ends do by experimentation. Thanks again, it's great to have context beyond the source. On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/15/2017 12:10 PM, Jon

On 9/25/2017 9:14 AM, Björn Pettersson A wrote: > > (Not sure if this exactly maps to “truncating store”, but I think it > at least touches some of the subjects discussed in this thread) > > Our out-of-tree-target need several patches to get things working > correctly for us. > > We have introduced i24 and i40 types in ValueTypes/MachineValueTypes > (in addition to

Hi All, I need to parse data from a file, example shown below. The first two lines can be skipped, the third line contains the column names. The next 13 lines can be skipped. The next line "1991" is a year value, with the following 13 values data for that year. The file then repeats this format with (year, 13 lines of data for that year). I would ideally like to end up with an

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

(Not sure if this exactly maps to “truncating store”, but I think it at least touches some of the subjects discussed in this thread) Our out-of-tree-target need several patches to get things working correctly for us. We have introduced i24 and i40 types in ValueTypes/MachineValueTypes (in addition to the normal pow-of-2 types). And we have vectors of those (v2i40, v4i40). And the byte size in our

So what is the correct behavior of the store <2 x i2>. Storing two bytes with a zext:ed i2 in each, or a bit packed vector? I can't remember any documentation mentioning that vectors are bit packed. But if LLVM is supposed to bit pack vectors, should we do it for any element size, or only when element size is less than the byte size, or only for i1 vectors? Maybe bit packing should be

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

Taking the address of a function inhibits optimisations for that function. Essentially any ABI changes are unavailable if we can't adjust the call site to match. The case of interest here is when a given function is called directly and indirectly, and we don't want the latter to impose a cost on the former. One approach to avoid the ABI constraint cost is to extract/outline the body of an

Does llvm have a pass that minimizes the bitwidth of llvm instructions? For instance:   %8 = and i32 %7, 63 63 is 111111 in binary. So the 'and' instruction only requires 6 bits. We could rewrite the above code as:   %8 = trunc i32 %7 to i6   %9 = and i6 %8, 63 Since we only need the lower 6 bits we could also propagate this change backwards to reduce the bitwidth of prior

*Problem-1* CASE-I---------(works fine) > var1<-"tom" > var1 [1"tom" > var1<-as.character(var1) > var1 [1] "tom" > var2<-c("tom","harry","kate") > logc<-(var1 %in% var2) > logc [1] TRUE > typeof(var1) [1] "character" > typeof(var2) [1] "character"

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 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

Dear R-help, I have a series of data.frames (i1,i2,...,in) all containing the same number of items, but dissimilar content. I would like to instal them in another data.frame, say index, so that I can access their items with index[i,j]. No matter how I try to set index up, its subframes cannot be indexed, because they all have the row number of 1. What am I doing wrong? (I get the same

I have dataframe with 17factors variables (for example every factor have 3levels) I have maybe 5000 observation. And i need to do table where is in every raw 1 of possible combination of this factors and the numbur how many time is this combination in my dataset. I wrote one code, but this is very slow and dumb. it looks like this: i<-0 for(i1 in levels(hivdat$pohl)){

It seems that that it's hard to vectorize int64 in LLVM. For example, LLVM 3.4 generates very complicated code for the following IR. I am running on a Haswell processor. Is it because there is no alternative AVX/2 instructions for int64? The same thing also happens to zext <2 x i32> -> <2 x i64> and trunc <2 x i64> -> <2 x i32>. Any ideas to optimize these

Hi all, I am trying to merge 2 big data.frame. The problem is merge is memory intensive so R is going out of memory error: cannot allocate vector of size 360.1 Mb. To overcome this, I am exploring option of using data.table package. But its not helping in term of memory as merge in data.table is fast but not memory efficient. Similar error is coming. My inputs are inp1 V1 V2 1 a i1 2 a i2 3 a