search for: truncstor

From what I can tell, the truncstore paths all fail instruction selection in the current PTX backend. This is easy to work around for int types >= 16 bits by setting the truncstore action to expand in PTXISelLowering.cpp, but this cannot handle i8 values, since the PTX backend has no register representation for i8s. As a result of...

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 (and (load MEM:$mem), (i32 0xffff0000)) , GPR:$val ) )>; And you can also write a custom rule for truncstore8 if necessary. Se...

Hi John, On Tue, 14 May 2019 at 17:51, Joan Lluch <joan.lluch at icloud.com> wrote: > This problem is also shared by the MSP430 target, and it’s very easy to reproduce by just compiling the code that I posted before. That's some good detective work; it definitely explains what you're seeing. Since MSP430 is affected it would probably be pretty easy to upstream an alignment-aware

...to ValueTypes.h, ValueTypes.td, and ValueTypes.cpp, the addition of the new integer types would also require changing (at least): 1. TableGen/CodeGenTarget.cpp - recognize and generate code for the new types 2. LegalizeDAG.cpp - eliminate power-of-2 assumptions in the legalization of extload and truncstore operations. 3. SelectionDAGBuild.cpp - add types to assertsext/assertzext generation in getCopyFromRegs() 4. TargetLowering.cpp - eliminate power-of-2 assumptions in computeRegisterProperties() 5. <Arch>ISelLowering.cpp - specify actions to lower the new types and the operations that use...

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 >

The example code: ; ModuleID = 'struct_2.bc' target datalayout = "E-p:32:32:128-f64:64:128-f32:32:128-i64:32:128-i32:32:128-i16:16:128-i8:8:128-i1:8:128-a0:0:128-v128:128:128-s0:128:128" target triple = "spu" @boolvar = internal global i1 false define void @set_boolvar() nounwind { entry: store i1 true, i1* @boolvar, align 16 ret void } This gets

...ueTypes.cpp, the addition of the new integer types would also > require > changing (at least): > > 1. TableGen/CodeGenTarget.cpp - recognize and generate code for the new > types > > 2. LegalizeDAG.cpp - eliminate power-of-2 assumptions in the > legalization of extload and truncstore operations. > > 3. SelectionDAGBuild.cpp - add types to assertsext/assertzext > generation > in getCopyFromRegs() > > 4. TargetLowering.cpp - eliminate power-of-2 assumptions in > computeRegisterProperties() > > 5. <Arch>ISelLowering.cpp - specify actions to low...

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

Hi Chandler, all, Why aren't the vector [zs]extloads introduced by SSE4.1/AVX2 declared legal? Is it a simple oversight, or did I miss a deeper reason? While cleaning up PMOV*X patterns, I stumbled upon this braindead testcase: %0 = load <8 x i8>* %src, align 1 %1 = zext <8 x i8> %0 to <8 x i16> turning into: pmovzxbw (%rsi), %xmm0

.... Further investigation is needed to find the right way forward here. * For optimizations to be supported, the combiner will become a crucial part of the GISel pipeline. We have already done some preliminary work in a generic combiner, which will be used to eventually support combines of extloads/truncstores. We’ve had discussions on and off list about what we need from the new combiner. The summary is that we want the combiner to be flexible for each target to select from a library of combines, being as efficient as possible. The expression of the combines are currently written in C++, but one piece...

...his will be the first 5 bytes of 8 on a little-endian machine and the last 5 bytes of 8 on a big-endian machine. Thus with this implementation in general you need to allocate at least 8 bytes for a variable of this type. In order to always only write to the first 5 bytes I would need to generalize TRUNCSTORE to write to a range of bits starting from a possibly non-zero bit-offset. Even then I'm not sure it can always be done on all targets (see below). This doesn't seem worth the trouble. > Should (4) be the same as (5) since alloca / malloc are allocating an > array of the specific...

[snip] > The ABI boundary lowering requires types to be broken down further into > 'legal types' that can be mapped to registers. The secondary breakdown is > currently handled by TargetLowering::LowerCallTo() calling > getRegisterType() and getNumRegisters(). Most ABIs are defined in terms > of C types, not LLVM IR types, so there is a close connection between the C >

On Wed, Jul 27, 2011 at 3:50 PM, Matt Johnson <johnso87 at crhc.illinois.edu> wrote: > Hi Eli, > > On 07/27/2011 04:59 PM, Eli Friedman wrote: >> >> On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson >> <johnso87 at crhc.illinois.edu>  wrote: >>> >>> Hi All, >>>     I'm writing a backend for a target which only supports 4-byte,

On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote: > > From: Daniel Sanders > > Sent: 25 November 2014 17:39 > > To: Eric Christopher; Tom Stellard > > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1 > > > > > > > > I'd also like to propose the inclusion of

...e can just kill it. > >> >> * For optimizations to be supported, the combiner will become a crucial >> part of the GISel pipeline. We have already done some preliminary work in a >> generic combiner, which will be used to eventually support combines of >> extloads/truncstores. We’ve had discussions on and off list about what we >> need from the new combiner. The summary is that we want the combiner to be >> flexible for each target to select from a library of combines, being as >> efficient as possible. The expression of the combines are currently wr...

...ittle-endian machine and the last > 5 bytes of 8 on a big-endian machine. Thus with this > implementation in > general you need to allocate at least 8 bytes for a variable of > this type. > In order to always only write to the first 5 bytes I would need to > generalize > TRUNCSTORE to write to a range of bits starting from a possibly non- > zero > bit-offset. Even then I'm not sure it can always be done on all > targets > (see below). This doesn't seem worth the trouble. Seems ok for the initial implementation. We can worry about size reduction la...

...n just kill it. >> >> >> * For optimizations to be supported, the combiner will become a crucial >> part of the GISel pipeline. We have already done some preliminary work in a >> generic combiner, which will be used to eventually support combines of >> extloads/truncstores. We’ve had discussions on and off list about what we >> need from the new combiner. The summary is that we want the combiner to be >> flexible for each target to select from a library of combines, being as >> efficient as possible. The expression of the combines are currently wr...

Hi Eli, On 07/27/2011 04:59 PM, Eli Friedman wrote: > On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson > <johnso87 at crhc.illinois.edu> wrote: >> Hi All, >> I'm writing a backend for a target which only supports 4-byte, >> 4-byte-aligned loads and stores. I custom-lower all {*EXT}LOAD and >> STORE nodes in TargetISelLowering.cpp to take advantage of

Hi, I am having issues running a new backend that I created for a new architecture. I suspect these errors may have something to do with how I have the string setup in LLVMTargetMachine() below? Also - It would be great if someone could point me to a document that describes some of these error messages? For example what does t26 ..t4 mean? Thanks in advance for taking your valuable time to help

On Oct 7, 2007, at 11:23 AM, Duncan Sands wrote: > Now that I'm working on codegen support for arbitrary precision > integers (think i36 or i129), I've hit the problem of what > getTypeSize and friends should return for such integers (the > current implementations seem to me to be wrong). However it's > not clear to me how getTypeSize and friends are defined. > >