similar to: [LLVMdev] r98938 broke argument passing on MSP430?

On Fri, Jun 11, 2010 at 2:55 PM, Ben Ransford <ransford at cs.umass.edu> wrote: > Yesterday I noticed that MSP430 argument passing is broken in trunk; > see http://llvm.org/PR6573 for details and testcases.  The problem is > that calls aren't being preceded by instructions that put the > arguments into registers.  I backtracked my working copy and then > stepped forward

Hello, I'm considering creating an LLVM backend for a 16 bit processor and modelling it around the (experimental) MSP430 back end. When reviewing MSP430InstrInfo.td I see def MSP430Wrapper : SDNode<"MSP430ISD::Wrapper", SDT_MSP430Wrapper>; and can see in MSP430ISelLowering.cpp that ISD::GlobalAddress: ISD::BlockAddress: ISD::ExternalSymbol all get lowered to

On 25 Jul 2012, at 04:49, Paul Shortis wrote: > Hello, > > I'm considering creating an LLVM backend for a 16 bit processor and > modelling it around the (experimental) MSP430 back end. > > When reviewing MSP430InstrInfo.td I see > > def MSP430Wrapper : SDNode<"MSP430ISD::Wrapper", SDT_MSP430Wrapper>; > > and can see in MSP430ISelLowering.cpp

Hi everyone, I am puzzled by several instruction defines in MSP430. 1 def MOV16rr : Pseudo<(outs GR16:$dst), (ins GR16:$src), "mov.w\t{$src, $dst}", [ ]>; Because it's an empty dag pattern[ ], by what does instuction selector select intruction 'MOV16rr'? 2 let canFoldAsLoad = 1, isReMaterializable = 1, mayHaveSideEffects =

Hi, 1. This instruction is not selected automatically by the instruction selector. The instruction combine / select stages insert registercopies, and they are expanded later on by the copyRegToReg() function provided by the MSP430InstrInfo to this MOV16rr. 2. ReMaterializable means there is no need to find a way to preserve the value in a register : the instruction can be just be reissued

Hi LLVM-Devs, I have managed to complete updating our sources from LLVM v4.0 to v5.0, but I am getting selection errors for 'callseq_end'. I am aware that the 'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have added an additional argument to the TD descriptions for these. There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG',

Hello all, Is it well known that building LLVM with --enable-optimized causes RegisterPass calls to be removed from dynamically loadable libraries (i.e., those built with LOADABLE_MODULE=1)? For example, here's what happens to the Hello pass (ToT on Darwin, both with and without --enable-optimized): $ pwd /Users/ransford/llvm/lib/Transforms/Hello $ nm -j Release+Asserts/Hello.o | c++filt -p

Hi, The full trace stack: Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824! [ 85%] Building X86GenEVEX2VEXTables.inc... &nbsp;#0 0x000000000081b9b5

Working on a target I added this pattern: def : Pat<(v4i64 (load xoaddr:$src)), (QVFCTIDb (QVLFDXb xoaddr:$src))>; which represents an actual load followed by a necessary conversion operation. The problem is that when this matches any TokenFactor that was attached to the load node gets attached, not to the inner load instruction, but the outer conversion operation. This is

Hi Martin, Pseudo CALLSEQ_START was changed in r302527, commit message contains details on the changes. However CALLSEQ_END was not modified. If your made changes to ADJCALLSTACKUP to add additional argument, that may result in error. Thanks, --Serge 2017-09-15 19:09 GMT+07:00 Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org>: > Hi LLVM-Devs, > > I have managed

Hi Krzysztof, Today I try it on llvm9.0.0 version. &nbsp; def bos : RPPInstMMEMrr<OPC_STORE, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (outs), (ins MGPR:$rs1, SGPR32:$rbase, MGPR:$roffset, uimm2:$rshift), &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; !strconcat(opcodestr, ""), "$rs1,

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

def STOREbos { // InstructionEncoding Instruction RPPInst RPPInstMMEMrr &nbsp; field bits<32&gt; Inst = { 0, 0, 0, 1, rs1{2}, rs1{1}, rs1{0}, index{0}, 0, 0, 0, 1, 0, rbase{3}, rbase{2}, rbase{1}, rbase{0}, rbase{4}, roffset{4}, roffset{3}, roffset{2}, roffset{1}, roffset{0}, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; &nbsp; field bits<32&gt; SoftFail = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

Hello, I just built a virgin ToT (r98634) for release on vanilla Snow Leopard. It seems that the Hello pass doesn't want to load because of undefined symbols: builddir% ../llvm/configure --prefix=$(PWD)/../installdir --enable-optimized builddir% make builddir% make install && cd ../installdir installdir% bin/opt -load lib/libLLVMHello.dylib Error opening

Hi, For the development of a new micro-controller backend, I try to lowering the following store SDNode: t5: ch = store<ST2[%ptr2](align=4)> t0, Constant:i16<3>, FrameIndex:i16<1>, undef:i16 I have defined the following instruction and associated DAG pattern. def MOVSUTO_A_i32o : CLPFPU_A_i32o_Inst<0b1000001101,

You are welcome. I changed the pattern, the same old error pop up again, crash in the same place. Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: &nbsp; (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!

Hello, Several people have expressed interest in using LLVM to target MSP430 microcontrollers. Anton wrote an MSP430 backend as an exercise, and some of the nastiest parts are done (thanks Anton!), but the consensus seems to be that there's still quite a bit of work left to do before LLVM can replace the commercial and open-source compilers (IAR, CCE, CrossWorks, mspgcc, and so on) that

Hello, I'm considering creating an LLVM backend for a 16 bit processor and modelling it around the (experimental) MSP430 back end. When reviewing MSP430InstrInfo.td I see def MSP430Wrapper : SDNode<"MSP430ISD::Wrapper", SDT_MSP430Wrapper>; and can see in MSP430ISelLowering.cpp that ISD::GlobalAddress: ISD::BlockAddress: ISD::ExternalSymbol all get lowered to

Hello, Within the file "MSP430InstrFormats.td" there is a class called "MSP430Inst" which has "Instruction" as superclass. Within this class there is a field called "Inst" (field bits<16> Inst;) which gets assigned in classes which specifies a specific instruction format, e.g. IForm contains: let Inst{12-15} = opcode; let Inst{7} = ad.Value; let

Hello, I'm trying to understand how fitting source integer type width into target machine register width happens. My reading on LLVM codegeneration topics (few megabytes) so far didn't have this topic mentioned explicitly. As an example, how %1 = add nsw i32 %b, %a gets compiled into msp430 (16bit CPU) assembly as: add.w r13, r15 addc.w r12, r14 Using -print-before-all