similar to: PPC64 Disassembler

The `isBranch` flag is already set on the branch instructions. Furthermore, we do use the `isBranch()` query in a few places in the PPC back end, so this does work. Perhaps there's something specific about the lldb usage? Is it somehow possible that the `isBranch()` query is called on the wrong instruction? Would you be able to provide a test case that reproduces the issue? On Thu, Nov 30,

> 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 19.03.2016 16:25, Mehdi Amini wrote: > Hi, > > Can you elaborate what is the impact at the IR level? > If the point is just about how you lower for you target, why are you needing an IR level attribute? You backend if free to specialize the lowering for any intrinsic regardless the IR level attributes. As I explained in my reply to Philip, what I really need is a way to get

What are the correct target description side effect flags for instructions which may trap (e.g. divide / remainder)? The divide instruction in my backend currently has no flags set. I've enabled the MachineLICM pass and it's causing a miscompilation by hoisting a divide by zero instruction out of the loop. Clearly this pass needs to be made aware that this is not safe. The current

Hello LLVM, I'd like to check TSFlags in my AsmBackend code. However AsmBackend objects don't have a reference to MCInstrInfo, which is the only way I've seen to reach TSFlags. A quickie grep shows that none of the existing targets check TSFlags in their AsmBackends. Is there any reason I shouldn't check TSFlags in AsmBackend? If not, what's the best way to go about it?

Am Mittwoch, 26. September 2012, 11:18:20 schrieb Jakob Stoklund Olesen: > Hi Christoph, > > As you noticed, MCInstrDesc doesn't distinguish between variadic uses and > defs. Since variadic instructions will always require some kind of special > handling, it doesn't seem worthwhile to make the model more detailed. I don't see what makes them so different from other

Hello, I'm currently working on a rich disassembler for some ARM/Thumb environment. I wanted to keep most classes independent of the architecture, so I use MCInstrInfo and MCInstrAnalysis to find branch instructions (and other instructions writing to the program counter) and to differentiate between register definitions and uses to track all instructions the branch depends on. This works

Hi, I wonder if it is okay to add an operand that is not part of MCInstrDesc to an MI after isel? There are things going on like instruction combining, rematerialization etc, which may call MI with TI->get(opcode). If an MI would get replaced with a new instance of itself in this way, any previously added operands would get lost, as they are not part of the MCInstrDesc. RegAlloc, does

Hi all, I need to figure out why InstrEmitter::EmitMachineNode assumes that when the number of outputs of a MachineSDNode is greater than the number of defs in the corresponding MCInstrDesc, the outputs in the difference will be placed into physical registers as opposed to virtual registers. The specific line in question is: bool HasPhysRegOuts = NumResults > NumDefs &&

Hallo, I worked on how to handle the distinction between variadic defines and uses and my current solution is this: I introduce a new dag item in Instruction called VariadicOperandList, which by default is undefined. It keeps a marker variable_* and all operands which are placeholders for variable lists (like 'reglist' on ARM). I think it's the cleanest solution to keep them in a

> On Mar 21, 2016, at 9:14 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Mar 21, 2016, at 8:58 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote: >> >> On 19.03.2016 16:25, Mehdi Amini wrote: >>> Hi, >>> >>> Can you elaborate what is the impact at the IR level? >>> If the point is just about

On Feb 20, 2013, at 11:44 AM, Jim Grosbach <grosbach at apple.com> wrote: > I'm not sure. It certainly seems reasonable to me that the building could/should set default Define flags on operands based on the MCInstrDesc. Dunno why it doesn't. Once you move beyond the fixed operands, it can't be determined automatically if the added register should be a use or a def. But I

Hi everybody, I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment - i.e. data that needs to be touched by the dynamic linker even though it's ultimately read-only, and data that cannot be shared between multiple processes using LLVM. It turns out that a solid ~1.3MB of that data is in the tablegen'd MCInstrDesc tables - there a pointers for ImplicitUses,

On Sep 24, 2012, at 6:39 PM, Christoph Grenz <christophg+llvm at grenz-bonn.de> wrote: > Is it possible to extend LLVM to check if 'variable_ops' is in 'ins' and/or > 'outs' in tablegen, so that MCInstrDesc could provide something like > hasVariadicDefs() and hasVariadicUses()? > > That way handling variadic instructions when disassembling would be

Hi Quentin, Thanks, that explanation makes sense. I can see that in a normal register machine, implicitly defs must be physical registers. In a stack machine like WebAssembly, though, implicit defs are known to be pushed onto the value stack just like any other defs. Slots on the value stack are represented by virtual registers until stackification, so for WebAssembly we do need the implicit defs

On 09.05.2016 05:19, Benjamin Kramer wrote: > On Mon, May 9, 2016 at 5:35 AM, Nicolai Hähnle <llvm-dev at lists.llvm.org> wrote: >> Hi everybody, >> >> I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment >> - i.e. data that needs to be touched by the dynamic linker even though it's >> ultimately read-only, and data that cannot be

Hi all, I am looking at the scheduling model of the ThunderX2. I am trying to figure out the cost of the LDADDALX instruction. The following program’s output is: name LDADDALX; class 872 microops 65535 I would have assumed that the microops are less than 20. The ThunderX2 has a detailed cost model for LSE. Could somebody tell me what I am doing wrong? Cheers, Tom #define GET_REGINFO_ENUM

On Feb 20, 2013, at 1:22 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Feb 20, 2013, at 11:44 AM, Jim Grosbach <grosbach at apple.com> wrote: > >> I'm not sure. It certainly seems reasonable to me that the building could/should set default Define flags on operands based on the MCInstrDesc. Dunno why it doesn't. > > Once you move beyond

Hi all, I'm currently investigating a bug which is causing an assert to fail in lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp. See https://llvm.org/bugs/show_bug.cgi?id=28753 for repro information. To my knowledge, this problem only occurs with the SystemZ target. I'm trying to determine whether the issue is the result of an edge case in the scheduling code itself, or if it's a

On Feb 20, 2013, at 1:27 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Feb 20, 2013, at 1:22 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> >> On Feb 20, 2013, at 11:44 AM, Jim Grosbach <grosbach at apple.com> wrote: >> >>> I'm not sure. It certainly seems reasonable to me that the building could/should set default