similar to: Manually insert an instruction in SelectionDAG

Hi Tim, Thank you for that. I was just trying to replicate the branch instruction under a new opcode, so I don’t think that returns a value. Plus the code I was testing out didn’t have a br or my newly added instruction but it still threw that error at me. Here’s the IR code I tested: ; ModuleID = ‘cc.c’ source_filename = “cc.c” target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128”

Hi Tim, Thank you for the quick response! so you'd probably check you're looking at a BranchInst and check BI->getSuccessor(0)->getName() (& 1 if it's conditional) I initially was printing out the result from getName() (I.getParent()->getName()) and it printed out nothing sadly. when parsing the instructions in SelectionDAGBuilder but it was only visiting instructions in

I duplicated an instruction in llvm and changed its opcode by following the guide at https://llvm.org/docs/ExtendingLLVM.html (Adding a new instruction) and then fixed the dependencies that caused an error when building. Now the modified llvm builds but throws but now throws the error: llc: error: llc: check.ll:12:3: error: instruction expected to be numbered '%5' %4 = alloca i32, align

Hello, I’m trying to insert an instruction if a specific label name/string is encountered and would appreciate some guidance on where I should start. Basically when parsing going through this .ll file: ; Function Attrs: noinline nounwind optnone uwtable define i32 @main(i32, i8**) #0 { %3 = alloca i32, align 4 %4 = alloca i32, align 4 %5 = alloca i8**, align 8 %6 = alloca i32, align

Hi all, The AsmPrinter class supports functions like EmitInt8, EmitInt16, and EmitInt32 for writing a 1/2/4 byte directive to the assembly. Each of these calls the MCStreamer::EmitIntValue method with the corresponding size. For some reason, there is no EmitInt64, and I was wondering if there was a fundamental reason why? The EmitIntValue function appears to support 8-byte inputs. I dug into

DWARF already needs to emit 64-bit values, being the type-unit hashes. How is that being done? (If it's going directly to the streamer, then we're already assuming all assemblers are okay with what the streamer does, and adding an AsmPrinter helper seems very reasonable.) --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of James Henderson via llvm-dev Sent:

> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. This is exactly what I was missing. Thanks a ton! :) -- Sanjoy Das http://playingwithpointers.com

Jim, I see routines that are already available to do the endianizing, but the data and text section contents don't have sizing for the individual elements as far as I can see so that I can endianize them. That is the part I am trying to solve, not the bit twiddling algorithm. Did I miss something? Jack ________________________________________ From: Jim Grosbach [grosbach at apple.com] Sent:

Proposal for ELF text and data big endian support for direct object generation Unless I am mistaken, currently big endian support in the MC layer for ELF direct object generation is limited to ELF headers and tables like relocations. Text and data section contents are still generated as individual bytes. It looks as if the effort was started, but never completed. The proposal is to extend the

Hi, I'm with a team using 16-bit bytes for an out-of-tree target. The AsmPrinter framework's implementation of the DWARF debugging format is not very good at distinguishing between target-sized bytes (which is the more common use) and 8-bit-bytes. The DWARF standard itself seems not very good in this regard, actually. So we have had to hack our way around this. I.e., at some call-sites of

On Oct 18, 2011, at 2:33 PM, Sanjoy Das wrote: >> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. > > This is exactly what I was missing. Thanks a ton! :) We have three pseudo expansion passes: 1. ExpandISelPseudos.cpp - For instructions that may need to create basic blocks, like CMOV and atomics. 2. ExpandPostRAPseudos.cpp - For instructions used to trick the

Hi Jack, Everything should be already using the sized Emit* routines directly rather than outputting individual bytes of larger entities piecemeal. Have you found that not to be the case? The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform:

Hi Jack, I would have expected the Mips backend to be using these routines (or more likely something on top of them) to emit the contents of the data and text sections and thus have the bit-twiddling done by these routines. I take it that's not happening? Basically, this should already work without any additional infrastructure. If it's not, something is broken and bypassing the

0x0f 0x6f 0xc8 And 0x0f 0x7f 0xc1 Should both be movq % mm0, % mm1. (AT&T) However, llvm 3.4 at least does not recognise the second variant as being a valid instruction. We are currently compiling up latest src incase it has been fixed. If not, could someone take a look or recommend how to fix? Lee -------------- next part -------------- An HTML attachment was scrubbed... URL:

H all, I'm looking at generating PIC code for RISC-V in the context of Linux. Not sure if anyone is working on this already, any inputs are very welcome. I'm now looking at function calls which in the RISCV backend are represented via two pseudoinstructions RISCV::TAIL and RISCV::CALL. Currently those pseudos are lowered in MCCodeEmitter. They are expanded into AUIPC and JALR

> But where is the flat set? Maybe I can debug and check what is going on. The MCInstrDesc are in a table in lib/Target/PowerPC/PPCGenInstrInfo.inc of your build directory. > Some additional information: > > MCInst opcode: 0x7cb > Decode Index: 0x1e I had assumed this would have dissembled to '// Inst #234 = BC' which does have the branch flag set, but I think that

On 04/30/2013 11:53, Rafael Espíndola wrote: > Are you trying MCJIT?:-) No. > > I first tried to compensate for that in MCJIT by adding those 4 bytes. > That works for Linux, but not for OS X where __register_frame takes a > single FDE at a time. I have an incomplete wip patch if you are > interested. On BSD __register_frame also takes a single argument and therefore needs

Hi, I'm implementing __builtin_setjmp and __builtin_longjmp for Sparc 32 bit processors (64 bit later, time allowing). I'm basing the code on the PowerPC version, which itself is based on the X86 version. This code is very nearly working, and I've had it working for -O0 optimisation (with a slightly different version to that below), so I know it's close. However, the PowerPC

On Wed, Oct 20, 2010 at 2:56 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Gosh, this is taking a while :-) >> Is there anything else I missed? > > Another one I noticed. Instead of > >      SmallString<32> *FC = &currFileFragment.getContents(); >      (*FC) += static_cast<char>(attr); >      (*FC) += static_cast<char>(0xFF

Hello I think I found a bug in the x86 instruction definition file, while trying out the disassembler. It looks like the "ADD32rr_alt" instruction should have GR32 operands, not GR16. Attached you can find a patch, which should fix the problem. But even with the change I can not decode e.g. "0x03 0xC1" (should be "addl %ecx, %eax") only if I remove the