similar to: [LLVMdev] RFC building a target MCAsmParser

On 06/25/2013 04:46 PM, Jim Grosbach wrote: > Hi Sid, > > This feels like it’s exposing too much of the disassembler internals > into the MCOperand representation. I’m not sure I follow why that’s > necessary. Can you elaborate a bit? > A packet contains 1-4 insns and until the contents of the entire packet are known the meaning of any individual insn is not known with 100%

I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type, "kAux" to the MCOperand class. The reason for this is that each insn has parse bits which are not explicit operands and have differing meanings based on the insn's location within the packet and the number of insns inside the packet. In order for the disassembler

Hi Sid, This feels like it’s exposing too much of the disassembler internals into the MCOperand representation. I’m not sure I follow why that’s necessary. Can you elaborate a bit? -Jim On Jun 25, 2013, at 8:24 AM, Sid Manning <sidneym at codeaurora.org> wrote: > > I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type,

On Oct 17, 2012, at 3:29 PM, David Young <davidy at codeaurora.org> wrote: > Hi, > I’m trying to enable the hexagon LLVM assembly parser. It seem like there is a lot of work that has been done to make this parsing straightforward. > > But…. > Hexagon assembly does not follow the “Mnemonic Rx Rx …” format that is expected by the assembly parsing infrastructure,

Hi, I'm trying to enable the hexagon LLVM assembly parser. It seem like there is a lot of work that has been done to make this parsing straightforward. But.. Hexagon assembly does not follow the "Mnemonic Rx Rx ." format that is expected by the assembly parsing infrastructure, represented by: StringRef Mnemonic = ((ARMOperand*)Operands[0])->getToken(); This

Hi all, I am trying to compile with a minimal TestAsmParser class, but I get the following error. ---------------- [43/780] Linking CXX executable bin/llvm-mc FAILED: : && /usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11

Hi All, The following code : void hexagon2( int *a, int *res ) { int i = 100; while ( i-- ) { *res++ = *a++; } } gets compiled as a sub-optimal Software loop on LLVM 9.0 instead of a Hardware loop, whereas it was compiled as a Hardware Loop in LLVM 7.0. This is the final assembly code generated by LLVM 9.0 : .text .file "main.c" .globl hexagon2 // --

Hi, I try to create a backend to support AsmParser, but it hasn't the red part as below. I find the Mips has this. Do you know how to make it appear? Jonathan #ifdef GET_ASSEMBLER_HEADER #undef GET_ASSEMBLER_HEADER // This should be included into the middle of the declaration of // your subclasses implementation of MCTargetAsmParser. unsigned ComputeAvailableFeatures(uint64_t

Hello, I want to implement LLVM backend for a specific VLIW hardware. I am working on defining its instruction set, and assembly language. The hardware has two pipelines, int and float. Each pipeline can do 3 operations/cycle, 3 operations forms an instruction. One of the Integer Instruction looks like this: add Ri, Rj, Rk; add Rl, Rm, Rn; add Ro, Rp, Rq An int instruction and a float

Dear list, I noticed that the Hexagon disassembler has issues with disassembling some firmwares I have. When tracing one of these problems, the handling of some new-value instructions in HexagonDisassembler::getSingleInstruction() turned out to be the cause, specifically this statement: [lines 384-386 in HexagonDisassembler.cpp in HEAD] else if (SubregBit) // Subreg bit should not be

Hello, I am experiencing problems, when trying to assemble these two x86-64 Opcodes "add r64, imm32" "imul r64, r64, imm32" When having the most significant bit set for imm32, for example: "add rax, 0x80000000", "add rax, 0xffffffff", ... "imul rbx, rsi, 0x80000000", "imul rbx, rsi, 0xffffffff", ... The Error Message I receive is the

Hi everyone, we've been prototyping an optimizing assembler for Hexagon for the purpose of updating legacy assembly for new architectures, packet rules, and instruction latencies. It seems like others would be interested in using this and we're looking for any related feedback: has it been attempted before, who's interested, or any general suggestions. We're using the

I am currently trying to compile a pretty simple program to work on an experimental board. It contains an (FPGA-version of) an ARMv4 processor. So basically, I try this (on my Ubuntu 18.04.1 LTS): clang -v --target=arm-none-eabi -c barehello.c -o barehelloCLANG.o clang -v --target=arm-none-eabi -c io.c -o io.o clang -v --target=arm-none-eabi barehelloCLANG.o io.o -o helloCLANGstatic -static

Hello, on the problems cross-building compiler-rt: Tried to follow https://llvm.org/docs/HowToCrossCompileBuiltinsOnArm.html which lead to this cmake: cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF

Jonathan <gamma_chen at yahoo.com.tw> wrote: > I try to create a backend to support AsmParser, but it hasn't the red part > as below. I find the Mips has this. Do you know how to make it appear? > > Jonathan > > #ifdef GET_ASSEMBLER_HEADER > #undef GET_ASSEMBLER_HEADER > // This should be included into the middle of the declaration of > // your subclasses

Hello again! Tried out the small Hello World Setup, worked as intended: root at christian-forschung-virtual-machine:/home/progs# clang -v --target=arm-linux-gnueabihf hello.c -o hello -fuse-ld=lld clang version 8.0.0 (https://git.llvm.org/git/clang.git/ a152c7a4b7ba8f4cb9532ead9a38a7121db43d50) (https://git.llvm.org/git/llvm.git/ 1959ce6f3e01241919968ac1911fd45660239d23) Target:

Hello again Christian, I've posted https://reviews.llvm.org/D55709 to see if we can get the documentation on how to cross-compile compiler-rt improved. I'll be out of office until next year so I may be a bit slow to respond to any follow ups. Peter On Thu, 13 Dec 2018 at 17:10, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Christian, > > I've just

Hello Peter and Lists, thanks a lot, that way it worked out! The final cmake was cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF -DCMAKE_C_COMPILER=/usr/local/myclang/bin/clang -DCMAKE_AR=/usr/local/myclang/bin/llvm-ar

Hello Christian, I've put some comments inline, On Sun, 3 Feb 2019 at 13:11, Christian Richter <christian.richter at hsu-hh.de> wrote: > > Hello again, > > so after I successfully build the compiler-rt for armv6 I tried to > actually use it in compiling a small helloworld for a baremetal arm > (consisting of barehelloCLANG.c and a small io.h + io.c) , but the >

Hello Christian, I'd expect that adding the library paths (-L) from gcc -v should fix the unable to find -lc, -lm but it won't fix the -lclang_rt.builtins-armv6m.a . To get clang_rt.builtins-armv6m.a you will need to cross compile compiler-rt for v6m and copy it to /usr/local/myclang/lib/clang/8.0.0/lib/baremetal . Beware that building compiler-rt for v6m does need quite a bit of fighting