search for: x86geninstrinfo

...GenInstrInfo.inc file for the OperandInfo used by the instruction, the question is what am I doing wrong ? 2. I've noticed that TwoOperandAliasConstraint does not appear anywhere in source/lib/Target/X86/* yet TIED_TO occurs in 162 of the OperandInfo's in build/lib/Target/X86/X86GenInstrInfo.inc the question is how does TIED_TO happen if not by TwoOperandAliasConstraint ? thanks, Peter Lawrence. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151123/5efd8da0/attachment.html>

Hi, I had (naively?) expected that the instruction to move immediate to register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, MOV64ri32) would be marked with the flag MCID::MovImm via the X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). I do not see that to be the case. Can someone please tell me if my expectation is flawed? Is there a better/different way to determine to test for move immediate to register/memory instruction on X86 other that the existing interface MCID::isMoveImmediate()? Thanks, Bharadwaj ------------...

...at<>, and sometimes custom instruction selection is required. As a result, many instructions are defined without a pattern, and we often forget to set neverHasSideEffects = 1. $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc lib/Target/ARM/ARMGenInstrInfo.inc:727 lib/Target/X86/X86GenInstrInfo.inc:920 I don't think more than half of those UnmodeledSideEffects flags should be there. I want to stop inferring instruction properties from patterns in TableGen. It has become very hard to read instruction definitions when some properties are inferred, but only half the time. We can stil...

...:137: error: undefined reference to 'pthread_create' /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/thread:137: error: undefined reference to 'pthread_create' clang: error: linker command failed with exit code 1 (use -v to see invocation) [722/979] Building X86GenInstrInfo.inc... I'm currently at r315954. Anybody else seeing this? -- Dean

I am getting 'bad suffix on number' for lib\target\x86\X86GenInstrInfo.inc:304, 305, ... Tablegen is generating 0x0LLU instead of 0x0ULL and VS2008 does not like it. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100609/e56cd538/attachment.html>

The new SUBREG target-independent instructions aren't getting mayLoad/mayStore flags set correctly. For example, in the generated X86GenInstrInfo.inc file, there is only one entry for INSERT_SUBREG: { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, OperandInfo107 }, // Inst #5 = INSERT_SUBREG THe sixth field is zero, which means it doesn't have the the MayLoad flag set. x86-64 does have a few variants of...

...; >> Hi, >> >> I had (naively?) expected that the instruction to move immediate to >> register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, >> MOV64ri32) would be marked with the flag MCID::MovImm via the >> X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). >> >> I do not see that to be the case. >> >> Can someone please tell me if my expectation is flawed? Is there a >> better/different way to determine to test for move immediate to >> register/memory instruction on X86 other that the existing interface >&...

...ists.llvm.org> wrote: > Hi, > > I had (naively?) expected that the instruction to move immediate to > register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, > MOV64ri32) would be marked with the flag MCID::MovImm via the > X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). > > I do not see that to be the case. > > Can someone please tell me if my expectation is flawed? Is there a > better/different way to determine to test for move immediate to > register/memory instruction on X86 other that the existing interface > MCID::isMoveImmediate()?...

...) are static, public members. It would still be handy to expose an enum somewhere. This is to support something like: if (Inst.getOpcode() == X86::CALL64r) { if (Inst.getOperand(0).getReg() == X86::RIP) { // ... } } E.g., exposing some of the tablegened enums in X86GenRegisterInfo.inc and X86GenInstrInfo.inc would be very handy. Steve > > > On Oct 28, 2013 12:03 PM, "Stephen Checkoway" <s at pahtak.org> wrote: > I'm iterating over MCInsts and I'd like to examine particular instructions. For example, I'd like to look at all x86 CALL64m instructions. I may...

...gt;> >>> I had (naively?) expected that the instruction to move immediate to >>> register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, >>> MOV64ri32) would be marked with the flag MCID::MovImm via the >>> X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). >>> >>> I do not see that to be the case. >>> >>> Can someone please tell me if my expectation is flawed? Is there a >>> better/different way to determine to test for move immediate to >>> register/memory instruction on X86 other that the...

...om instruction selection is required. > > As a result, many instructions are defined without a pattern, and we often forget to set neverHasSideEffects = 1. > > $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc > lib/Target/ARM/ARMGenInstrInfo.inc:727 > lib/Target/X86/X86GenInstrInfo.inc:920 > > I don't think more than half of those UnmodeledSideEffects flags should be there. > > > I want to stop inferring instruction properties from patterns in TableGen. It has become very hard to read instruction definitions when some properties are inferred, but only ha...

On 9 June 2010 14:20, Aaron Gray <aaronngray.lists at gmail.com> wrote: > I am getting 'bad suffix on number' > for lib\target\x86\X86GenInstrInfo.inc:304, 305, ... > > Tablegen is generating 0x0LLU instead of 0x0ULL and VS2008 does not like > it. > Patch attached. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100609/bb59a373/attac...

On Mar 18, 2008, at 6:12 PM, Dan Gohman wrote: > The new SUBREG target-independent instructions aren't getting > mayLoad/mayStore flags set correctly. > > For example, in the generated X86GenInstrInfo.inc file, > there is only one entry for INSERT_SUBREG: > > { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, > OperandInfo107 }, // Inst #5 = INSERT_SUBREG > > THe sixth field is zero, which means it doesn't have the the > MayLoad flag set. I am...

...handy to expose an enum somewhere. This is to support something > like: > > if (Inst.getOpcode() == X86::CALL64r) { > if (Inst.getOperand(0).getReg() == X86::RIP) { > // ... > } > } > > E.g., exposing some of the tablegened enums in X86GenRegisterInfo.inc and > X86GenInstrInfo.inc would be very handy. > > Steve > > > > > > > On Oct 28, 2013 12:03 PM, "Stephen Checkoway" <s at pahtak.org> wrote: > > I'm iterating over MCInsts and I'd like to examine particular > instructions. For example, I'd like to look at...

...om instruction selection is required. > > As a result, many instructions are defined without a pattern, and we often forget to set neverHasSideEffects = 1. > > $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc > lib/Target/ARM/ARMGenInstrInfo.inc:727 > lib/Target/X86/X86GenInstrInfo.inc:920 > > I don't think more than half of those UnmodeledSideEffects flags should be there. > > > I want to stop inferring instruction properties from patterns in TableGen. It has become very hard to read instruction definitions when some properties are inferred, but only ha...

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

...instruction selection is required. > > As a result, many instructions are defined without a pattern, and we often > forget to set neverHasSideEffects = 1. > > $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc > lib/Target/ARM/ARMGenInstrInfo.inc:727 > lib/Target/X86/X86GenInstrInfo.inc:920 > > I don't think more than half of those UnmodeledSideEffects flags should be > there. > > > I want to stop inferring instruction properties from patterns in TableGen. > It has become very hard to read instruction definitions when some > properties are inferred,...

I'm iterating over MCInsts and I'd like to examine particular instructions. For example, I'd like to look at all x86 CALL64m instructions. I may be missing something, but it seems like my only option is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I could iterate through the opcodes and build up a table of the ones I'm interested in to avoid string

...e size suffix from the register. In your case, you used a segment register which we couldn't guess the size from. And then we printed a bad error message. There's no quick reference as such for the meaning of the various X86::XXXXXX names. But the complete list of them is in lib/Target/X86/X86GenInstrInfo.inc in your build area. The names are meant to be fairly straight forward to understand. The first part of the name should almost always be the instruction name from the Intel/AMD manuals. The lower case letters at the end sort of convey operand types, but often not the number of operands even thou...

...egment register > > which we couldn't guess the size from. And then we printed a bad error > > message. > > > > There's no quick reference as such for the meaning of the various > > X86::XXXXXX names. But the complete list of them is in > > lib/Target/X86/X86GenInstrInfo.inc in your build area. The names are > meant > > to be fairly straight forward to understand. The first part of the name > > should almost always be the instruction name from the Intel/AMD manuals. > The > > lower case letters at the end sort of convey operand types, but of...