similar to: [LLVMdev] Are Opcode and register mappings exposed anywhere?

See the source here: https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp. It looks like getRegisterName might do what you want, but I don't know where it's coming from. (Whether it's a function or a member of a super class. Hopefully, if it's a member, it's public.) PS Sorry for the duplicate, Stephen. I forgot to CC the list. On

On Oct 28, 2013, at 2:02 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> wrote: > See the source here: https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp. It looks like getRegisterName might do what you want, but I don't know where it's coming from. (Whether it's a function or a member of a super class. Hopefully, if it's

Can't you just include the generated files? What different way would you like them exposed? On Mon, Oct 28, 2013 at 11:23 AM, Stephen Checkoway <s at pahtak.org> wrote: > > On Oct 28, 2013, at 2:02 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> > wrote: > > > See the source here: >

I have a question regarding implementation of subclasses of MCInstPrinter. I am implementing Machine IR layer to MC layer lowering for Mips. What's the best way to print the value of "Register" in the following code in MCAsmStreamer::EmitRegisterName? Do I have to convert the LLVM register number back to its corresponding dwarf register number in function

Hi Eli, I have tried this, but the resulting tool-chain was broken. There are only two references to "CALL64m": the definition in X86Instr64bit.td, and an entry in X86InstrInfo.cpp. After commenting both out, compilation of a large application fails with: llc: ScheduleDAG.cpp:462: void llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion `Node2Index[SU->NodeNum]

After removing CALL64m, the resulting DAG has a cycle that cannot be scheduled. I've attached a PDF of the DAG before instruction selection (-view-isel-dags), and after instruction select (-view-sched-dags). Notice how the flag/chain relationships between MOV64rm and CALL64r make it impossible to schedule. Here's the code being compiled: define ccc void @ArgsFree() nounwind { entry:

On Tue, Jun 8, 2010 at 4:20 PM, David Meyer <pdox at google.com> wrote: > Hi Eli, > I have tried this, but the resulting tool-chain was broken. > There are only two references to "CALL64m": the definition in > X86Instr64bit.td, and an entry in X86InstrInfo.cpp. > After commenting both out, compilation of a large application fails with: > llc: ScheduleDAG.cpp:462:

On Jun 22, 2011, at 9:00 AM, Renato Golin wrote: > On 22 June 2011 16:50, Jim Grosbach <grosbach at apple.com> wrote: >>> This sounds like a dead end as newer binutils are GPLv3. >> >> Yeah, that's definitely a very real concern and a big motivation to get the MC based asm parser whipped into usable shape. We're much more in control of our own destiny then.

Hi, don't know if this is the right list. Please post a better place, otherwise. I'm currently writing a LLVM ModulePass and ran into strange segfaults or endless loops within LLVM. My main question is, if this is a programming error or API misuse from me or a LLVM bug? Here is some minimal code, that triggers the bug: ---------------- class DebugPass : public ModulePass { public:

Hi, I am attempting to modify LLVM to generate code for an architecture which is nearly identical to X86-64, but with a few minor differences. In particular, "call" must always have a register operand, and cannot have a memory operand. Any ideas on how I can express this rule? Thanks, - David -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Jun 22, 2011, at 6:15 PM, Jim Grosbach wrote: > > On Jun 22, 2011, at 9:00 AM, Renato Golin wrote: > >> On 22 June 2011 16:50, Jim Grosbach <grosbach at apple.com> wrote: >>>> This sounds like a dead end as newer binutils are GPLv3. >>> >>> Yeah, that's definitely a very real concern and a big motivation to get the MC based asm parser

Hi, I'd like to propose extending the supported syntax for AssemblerPredicates to allow sets of SubtargetFeatures to be listed, but where only one in the list has to be enabled for the predicate to be true. The condition string which forms a AssemblerPredicate already allows multiple features to be defined, separated by commas, and this means all of these features must be present. For

On Tue, Jun 8, 2010 at 2:05 PM, David Meyer <pdox at google.com> wrote: > Hi, > I am attempting to modify LLVM to generate code for an architecture which is > nearly identical to X86-64, but with a few minor differences. > In particular, "call" must always have a register operand, and cannot have a > memory operand. Any ideas on how I can express this rule? Just get

When compiling a release version on Linux with GCC 3.4.4, I get the following warnings repeated multiple times when linking LLVMCore.o: /usr/bin/ld: `.gnu.linkonce.t._ZNK4llvm11Instruction13getOpcodeNameEv' referenced in section `.gnu.linkonce.r._ZNK4llvm11Instruction13getOpcodeNameEv' of /proj/llvm/build/lib/VMCore/Release/Instruction.o: defined in discarded section

Hi Kurt, Jim, I took the liberty of working on this today. The patch has become a bit of a frankenpatch, for the reasons listed out below and so I won't be able to submit it until tomorrow. The actual fix itself was very straightforward, but exposed a failing in the FixedLenInstructionDecoder in that it does not support instruction predicates such as "IsThumb2". Generally this is

On Wed, 2018-02-07 at 21:55 +0000, David Woodhouse via llvm-dev wrote: > Can you take care of filing the tickets for %V0 and "=q" > and attribute__((indirect_branch("keep"))) please? With those fixed, I > think we should be OK again. Here's %V0 support, which makes the hypervisor guest support build. diff --git a/lib/Target/X86/X86AsmPrinter.cpp

I can see that I'm totally out of my depth on these changes. While I understand what both Jim Grosbach and James Molloy said, I do not believe I'm capable of producing code that fits into the LLVM ecosystem nicely. -Kurt On Tue, Aug 30, 2011 at 06:15:33PM +0100, James Molloy wrote: > Hi Kurt, Jim, > > I took the liberty of working on this today. > > The patch has become

Hello Everyone, I need some help in retrieving the numeric value of an instruction operand from LLVM IR. this is what the IR looks like for a simple add function that adds two i32 integers define i32 @summ(i32 %a, i32 %b) #0 { entry: %add = add nsw i32 %b, %a ret i32 %add } i would like to know the integer value of %a and %b. I've tried -i->getOpcodeName() which gives me the

On Wed, 2018-02-07 at 23:30 +0000, Chandler Carruth wrote: > This should go to llvm-commits as a proper review. Do you want to do > that David? Want someone on our end to pick it up? I'll attempt to add some test cases... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available

On Wed, Oct 27, 2010 at 1:29 PM, Brian West <bnwest at rice.edu> wrote: > Here is the patch for the new Operator Strength Reduction optimization > pass that I have written.  The bulk of the code is in > > lib/Transforms/Scalar/OperatorStrengthReduce.cpp > > The algorithm finds reduction opportunities in both array accesses and > explicit multiplications within loops.