similar to: [LLVMdev] cross-section differences in MC generation

Attached. You can also find it at http://people.freebsd.org/~jhibbits/hello_llvm.s . - Justin On Thu, Jun 26, 2014 at 1:26 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > > Sent from my iPhone > >> On Jun 26, 2014, at 12:33, Justin Hibbits <jrh29 at alumni.cwru.edu> wrote: >> >> I'm working on Position-independent code for

Aside from the fact that you're checking for i64 specifically instead of generally checking for illegal types, how much of this is really PPC specific? Would this be a reasonable enhancement to the SDAG logic in general? -Hal On 1/4/19 8:03 AM, Nemanja Ivanovic wrote: The changes seem fine to me. I don't think this is excessively intrusive and it accomplishes what is needed by targets

Hi Nemanja, I'm attaching a patch that builds on D54583 and implements what we discussed on IRC earlier today. Particularly: * Make LowerCallTo() a virtual function, so it can be wrapped by a subclass. * Implement LowerCallTo() in PPCTargetLowering to wrap TargetLowering::LowerCallTo() and legalize the return node when targeting SPE. * Augment PPCTargetLowering::LowerCall_32SVR4() to

I think that's incorrect. It should to: .section .foo .L1: .L2 = .L1 .section .bar .long .L3-.L2 .L3: Because .L3 and .L2 are in different sections. - Justin On Thu, Jun 26, 2014 at 2:46 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > This reduces to > > .section .foo > .L1: > .L2 = .L1 > .section .bar > .long .L1-.L2 > > > Which is fairly

+ Eli Friedman as he often has very insightful comments regarding back end changes. On Fri, Jan 4, 2019 at 9:03 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > The changes seem fine to me. I don't think this is excessively intrusive > and it accomplishes what is needed by targets whose call lowering can > introduce illegal types. > Adding Justin Bogner as the

I'm attempting to implement codegen support for the AVR ST/LD <http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_ST.html> family of instructions. The binary encoding is not particularly consistent -- take a look at this table of variants of LD, along with their machine code representation: # load 8 bits from pointer register X into general purpose Rd ld Rd, X `1001 000d dddd

On Mon, Sep 26, 2016 at 2:24 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 9/26/2016 3:58 PM, Phil Tomson wrote: > >> But don't the defs for ADDR_RR and ADDR_RI also contain dags? >> >> def ADDR_RR : Addr< 2, "SelectAddrRegReg", >> (ops GPRC:$base, GPRC:$offsetreg) >; >> def ADDR_RI :

Hi, My New Year's resolution is to complain (constructively) whenever I get a spurious build failure email from a buildbot. For new or infrequent contributors especially, they can be extremely confusing and unnecessarily alarming. This one below is the first build ever attempted by the builder, so how on earth can it have come up with a meaningful blame list? And in any case, surely we

hi! To continue the inflow of good news this week, let me announce that clang -integrated-as (ie. ELF part of MC) compiles all of FreeBSD! This includes things like booting kernel, gnu libstdc++, clang/LLVM itself and many other components that make up FreeBSD operating system. I personally consider this a milestone where -integrated-as should become the default for ELF/{x86_64,i386}. Many

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

A question for LLVM code generator developers: After having read through "The LLVM Target-Independent Code Generator" [1] I'm unclear about what precisely the objects MCInst and MCOperand represent. They sit in the space between assembly syntax and binary encodings, but which are they modeling? For example, a Thumb 2 branch instruction 'b' takes an immediate. That syntax

But don't the defs for ADDR_RR and ADDR_RI also contain dags? def ADDR_RR : Addr< 2, "SelectAddrRegReg", (ops GPRC:$base, GPRC:$offsetreg) >; def ADDR_RI : Addr< 2, "SelectAddrRegImm", (ops GPRC:$base, i64imm:$offsetimm) >; Do I need to create some other intermediate node type for a shifted address? Phil On

Tim, How about the below option ? 1. Specify an existing generic armv7 CPU or the CPU which is close my custom variant. My custom variant can be treated as "cortex-a9" + hwdiv. So my CPU here is "cortex-a9" 2. Specify the ".arch_extension idiv" which is available as an extension for my custom variant. 3. Teach LLVM & Clang about your CPU's

Hi, I have a custom lowering operation on ISD::BITCAST for the PowerPC/SPE target, to convert 'f64 bitcast (i64 build_pair i32, i32)' into a 'f64 BUILD_SPE64 i32, i32' node, which can be seen at https://reviews.llvm.org/D54583. However, when building compiler-rt's lib/builtins/divdc3.c an assertion is triggered that BUILD_PAIR is not legal on line 24. There should be no

I'm trying to add intrinsics for the Signal Processing Engine (FPU/vector unit) on some PowerPC cores, but running into a problem. Some of the instructions take an immediate operand, but I can't figure out how to make the intrinsic use an immediate, it just wants to load a register as an argument to the function. Is there any way in the .td file to describe the intrinsic as taking an

Hi In my MC6809 backend, in llvm/lib/Target/MC6809/InstPrinter/MC6809InstPrinter.cpp, I have the routine void MC6809InstPrinter::printPCRelImmOperand(const MCInst *MI, unsigned OpNo, raw_ostream &O) { const MCOperand &Op = MI->getOperand(OpNo); ZZ if (Op.isImm()) { int64_t Imm = Op.getImm() + 2; <<<======================== O << "$"; if (Imm

Hi, How do "Pat" operands get matched? I am trying to follow the example given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process In the latest trunk of ppcintrinfo.td following pattern is defined: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; I understand that input operand list i.e. ins of

Hi, everyone, I would like to know if anyone is still making use of the support in the PowerPC backend for the IBM BG/Q supercomputer, including the support for its QPX vector instruction set. If you are, please reply. I'm not aware of any still-running BG/Q machines, and if no one is making use of this functionality, I propose that we remove it. Thanks again, Hal Hal Finkel Lead, Compiler

Owen is correct in his descriptions. The MCOperand values are intended to model the instruction encoding. Where that doesn't match the assembly syntax, the asm parser (and codegen) and the instruction printer are responsible for encoding/decoding the values. For targets that predate the MC layer, this isn't always the case, leading to things being a bit confusing when just reading the

Hi all, I'm trying to make an LLVM backend for the Adapteva's Epiphany E16 CPU (used in Parallella board), using CPU0 and some other backends as examples, and I've got stuck with branching. When I'm printing out asm, all branch labels are printed as they should be. But when I'm trying to generate obj file, I'm getting zeros instead of PC-related offset in all branch