similar to: Wrong MachineOperand accessor

Hi, In further investigating my issue today I realized the assert doesn’t fail when I compile with a clang that doesn’t have my static sanitizer runtime library. Therefore, probably no one can reproduce my issue. Sorry about that. I will reply if I figure out a better repro. Thanks, Scott On Mar 28, 2016, at 7:44 PM, via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at

Hello! We are experiencing a problem with jit generated instructions for arm target (we have built llvm gcc for arm arch using the llvm sources fetched from llvm svn a few days ago). It triggers assert in MachineOperand::getImm method (isImm() && "Wrong MachineOperand accessor") when the bitcode from the testcase (c code below in this email) is being run. We have found out that

This seems a very natural approach but I probably am having a trouble with the iterator invalidation. However, looking at other peephole optimizers passes, I couldn't see how to do this: #define BUILD_INS(opcode, new_reg, i) \ BuildMI(*MBB, MBBI, MBBI->getDebugLoc(), TII->get(X86::opcode)) \ .addReg(X86::new_reg, kill).addImm(i) for

I need to modify the FPImmediate in the MachineOperand but there is no accessor function for this variable. Any other way of doing this without creating a new operand via CreateFPImm? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part

Hi Sergei, our use of target flags will be on immediate register operands if I am not mistaken (and if not we can always encode it as such)? I guess you are refering to the hexagon backend needing to distinguish between instances of an instruction that uses a constant value that can fit into the 4 byte of the instruction and one that encodes the immediate in an extra instruction slot (what we

On 10/10/11 19:19, Jakob Stoklund Olesen wrote: > On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: >> I'm investigating a bug associated with debug information that manifests >> itself in the XCore backend (PR11105). I'd like to understand what the >> expected behavior of eliminateFrameIndex() is when it is called on a >> dbg_value machine instruction. >

Arnold, I wanted to hear from Jacob is the original patch in question still needed, since our use of this field could surpass const extenders and could potentially include MO_Register. Jacob, Can you please comment? Thanks. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Arnold

Jakob and anyone else who might be interested... Base on this patch back in August, I sense some need to double check with you whether it is OK to start making a heavy use of MachineOperand TargetFlags? We do seem to have a compelling reason for it in Hexagon, and I wanted to make sure that it is OK with everyone. I plan to use it for attributing target specific info to MOs and in more general

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > OK, here's a new patch that adds the infrastructure and the > implementation for X86, ARM and PPC of GetInstSize and > GetFunctionSize. Both functions are virtual functions defined in > TargetInstrInfo.h. > > For X86, I moved some commodity functions from X86CodeEmitter to > X86InstrInfo. >

Hi David, I'm catching up on email at the moment so I don't know if you've done this, but patches should go to llvm-commits for review if you wouldn't mind. Thanks! -eric On Thu Dec 12 2013 at 8:39:19 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 > It also fixes a test which was requiring

Eli, Thanks for the tips. I've been able to get something working using a custom instruction inserter, however, I'm still having the problem of linking together the setcc and the select_cc commands. I want to turn the setcc into a comparison and use the results in the select_cc register. However, the comparison information is in the select_cc instruction and the result of the comparison

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

Hi, On the OpenMandriva side, x86_64 passes all checks. We're having some problems with other architectures though (see below): x86_64 succeeded, packages are here: https://abf.openmandriva.org/build_lists/76792 i586 fails to build, but this seems to be an issue with 3.8.1 (which we're using to build 3.9): /usr/bin/clang++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS

Hi all, The goal of this RFC is to make information related to variant scheduling classes accessible at MC level. This would help tools like llvm-mca understand/resolve variant scheduling classes. To achieve this goal, I plan to introduce a new class of scheduling predicates named MCSchedPredicate. An MCSchedPredicate allows the definition of boolean expressions with a well-known semantic, that

The instruction mnemonics for the immediate forms of bit-test instructions including bt, btr and bts, btc do not work. llvm-mc barfs with: error: ambiguous instructions require an explicit suffix This is highly user-unfriendly, since we can easily infer what the user meant by inspecting $imm and translating the instruction appropriately. Do it exactly as the Intel manual describes. Note that

Hello everyone, I'm working on a MachineFunctionPass that inserts a list of instructions into an Module so a later Pass can work on them. To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. I started with branch instructions:     const TargetMachine &TM = MF.getTarget();

On 03/22/2018 09:29 AM, Julius Hiller via llvm-dev wrote: > Hello everyone, > > I'm working on a MachineFunctionPass that inserts a list of instructions into an Module so a later Pass can work on them. > To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. > I started with

I'm doing the delay slot optimization for MIPS and I've noticed that two other ports that are doing this have to work around a problem in the instruction abstraction. Would be nice to fix this and not propagate the hack. The basic problem is that on a call, you want to get the set of explicit and implicit operands but NOT the variable operands. There is no way do this without

Gang, I'm tasked with direct object generation for Mips and am trying to not hack the code. I how exactly does one set an expression to be PC relative and if the compiler can resolve it, not produce a relocation? In our case, the backend produces an expression for the branch which is the target label. I make a call from the .td for the branch instruction which calls a routine in

Hi all, We have some code in Hexagon that needs to be run on MC instructions, as well as on MI instruction. Here is some background for why we have this need: Some Hexagon instructions can be converted to a more compact bit representation, with the exact same functionality, if the properties of its operands meet certain criteria. Thus on the MI layer, we check the properties of the