similar to: [LLVMdev] byte store requires read-modify-write sequence

Hi, > Our processor only does 32bit reads and writes to memory. Changing a > byte requires a 32bit read, modify, 32bit write sequence to change the > 8bit value in memory. > > How should this be handled? your backend will have i32 as a legal type and i8 as an illegal type. A store to an i8 will be automatically transformed into a "truncating" to i8 store of i32.

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

Please open a bugzilla ticket and attach your testcase. It will allow us to debug and fix the problem. Thanks - Elena From: JinGu [mailto:jingu at codeplay.com] Sent: Saturday, September 16, 2017 00:38 To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com <daniel_l_sanders at apple.com>; Jon Chesterfield <jonathanchesterfield at

I am a very amateur Rubyist who, amongst other things, likes to use a simple Rails app to query my company''s MySQL config database. The server I now use to do this has got 1.9.1 and Rails 2.3.3. I''ve now hit the ''problems'' related to 1.9 and string encoding, which means that when Rails try to display, say, E acute characters, it throws an invalid byte

> extends the elements to 8bit and stores them on stack. Store is responsible for zero-extend. This is the policy... - Elena -----Original Message----- From: jingu at codeplay.com [mailto:jingu at codeplay.com] Sent: Friday, September 15, 2017 17:45 To: llvm-dev at lists.llvm.org; Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com Subject: Re: Question

On my target store/load of f32 or i32 are equivalents. Previously I had duplicate instructions def in .td to map f32 and i32 to the same opcode. I deleted all that and I instead tried a new approach (to simplify things) : setOperationAction(ISD::STORE, MVT::f32, Promote); AddPromotedToType(ISD::STORE, MVT::f32, MVT::i32); setOperationAction(ISD::LOAD, MVT::f32, Promote);

> so I think we need to use non-extending load for element size less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. > if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { > return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); > } else { > return

On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > On my target store/load of f32 or i32 are equivalents. > Previously I had duplicate instructions def in .td to map f32 and i32 to > the same opcode. > > I deleted all that and I instead tried a new approach (to simplify things) : > > setOperationAction(ISD::STORE, MVT::f32, Promote); >

On Mon, Aug 5, 2013 at 2:25 PM, Tom Stellard <tom at stellard.net> wrote: > On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > > On my target store/load of f32 or i32 are equivalents. > > Previously I had duplicate instructions def in .td to map f32 and i32 to > > the same opcode. > > > > I deleted all that and I instead tried a new approach

On Wed, Jun 26, 2019 at 12:38 PM Tim Northover <t.p.northover at gmail.com> wrote: > Hi Gleb, > > On Wed, 26 Jun 2019 at 07:28, Gleb Popov <6yearold at gmail.com> wrote: > > def StoreStackF : InstRI<2, (outs), (ins IntRegs:$reg, i32imm:$i), > > "storestackf $reg, [$i]", [(store_stack i32:$reg, > AddrFI:$i)]>; > > >

How can I custom lower the ISD::STORE? I am using -enable-legalize-types and trying to customize most of our operations in xxxTargetLowering::ReplaceNodeResults(...) There are hooks to get trunk-store and indexed-store customized, But I can't get regular STORE customized... Any suggestions? Thanks Alireza Moshtaghi Senior Software Engineer Development Systems, Microchip Technology

This code lives in DAGCombiner.cpp: ------------- // Turn 'store float 1.0, Ptr' -> 'store int 0x12345678, Ptr' if (ConstantFPSDNode *CFP = dyn_cast<ConstantFPSDNode>(Value)) { // NOTE: If the original store is volatile, this transform must not increase // the number of stores. For example, on x86-32 an f64 can be stored in one // processor operation but

On Jun 4, 2010, at 1:57 AM, <Kalle.Raiskila at nokia.com> <Kalle.Raiskila at nokia.com> wrote: > On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: >> If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. >> > Tried it, and it seems to break quite a big chunk of our tests on SPU :)

Hi, Within a basic block I can remove unnecessary register copies + zero sign extensions of unsigned-8bit-loaded values by implementing isZExtFree() for ISD::LOAD nodes. ...But not between basic blocks. The first block does a CopyFromReg of the unsigned-8bit-loaded vreg1 into a new vreg2. The second block then does a unnecessary zext to vreg2. What I want is the 2nd block to use the original

Hello. After "Initial selection DAG" stage I get a DAG with node t14: ch = store<(store 4 into %ir.p45, align 8, addrspace 1)> t10, FrameIndex:i32<2>, FrameIndex:i32<3>, undef:i32 1. Where does it come from? Can I do anything to make it not appear? 2. If not, how do I change it so that the operand being stored would be first loaded into a register, and that register

Hi James, Jim If you *really* want this to work in selection DAG then there is a solution, but its not pretty. First make i64 not be legal. Then, assuming the regclass you gave has some subregs, you can give load/store a custom legalisation where you change the i64 to MVT::Untyped. So something like this for ISD::STORE: SDValue ValueToBeStored = St.getOperand(…) auto SeqOps[] = {

Thanks again for your help Steve, I’m thinking perhaps my “SelectADDRrr” pattern is inadequate. The sign-extension is at the hardware level, the code generator sees (should see) it as a 16-bit signed register value. My implementation is just: bool SHAVEISelDAGtoDAG::SelectADDRrr(SDValue &Addr, SDValue &Base, SDValue &Offset) { if ((Addr.getOpcode() == ISD::ADD) { Base

In http://reviews.llvm.org/D8713, I added the 64bit integer store ("std") and load ("ldd") instructions for 32bit sparc. But now I need codegen to know how to emit them, and am not sure the best way to go about teaching the backend that 64bit integers can be used natively, but only for loads and stores. (I originally wrote an earlier draft of question in the review but it