search for: offset32

Hi Jun, I'm not sure how to fix this yet, but this looks incorrectly defined in lib/Target/X86/X86InstrInfo.td: def MOV32o32a : Ii32 <0xA1, RawFrm, (outs), (ins offset32:$src), "mov{l}\t{$src, %eax|eax, $src}", [], IIC_MOV_MEM>, Requires<[In32BitMode]>; This instruction can be REX-prefixed for a 64-bit move, and that also doesn't appear to be defined anywhere. I would file a bugzilla in the x86 com...

Hi, With objdump, i have this (Intel syntax) 64 a1 00 00 00 00 mov eax,fs:0x0 However, if I pass above string to llvm-mc, I would have: $ echo "0x64 0xa1 0x00 0x00 0x00 0x00"|./Release+Asserts/bin/llvm-mc -disassemble -arch=x86 --output-asm-variant=1 .text mov eax, dword ptr [0] You can see a big difference. This is on the latest code. Any idea how to

On Thu, Nov 28, 2013 at 1:03 AM, Kay Tiong Khoo <kkhoo at perfwizard.com>wrote: > Hi Jun, > > I'm not sure how to fix this yet, but this looks incorrectly defined in > lib/Target/X86/X86InstrInfo.td: > > def MOV32o32a : Ii32 <0xA1, RawFrm, (outs), (ins offset32:$src), > "mov{l}\t{$src, %eax|eax, $src}", [], IIC_MOV_MEM>, > Requires<[In32BitMode]>; > > This instruction can be REX-prefixed for a 64-bit move, and that also > doesn't appear to be defined anywhere. > > I wou...

Hello LLVM Community, I am interested doing following project with LLVM for GSoC 2016. Code Generation Improvements: Particularly Generalize target-specific backend passes that could be target-independent I have done some initial study and try to understand the task to be done. Please help me to develop the proposal. Following are my initial findings : 1. lib/Target/Hexagon/RDF* : Code

...;t an option on AArch64 (it can only happen with OS support and never happens within a single process on a sane OS). This pass is more a matter of putting the IR in a form that precisely matches the addressing modes that are actually available. AArch64 can encode addresses like "base64 + sext(offset32)" into the actual load/store instruction so it's advantageous to put the sext as close as possible to the pointer dereference. I'm afraid I don't really know enough about other architectures to say which could benefit. It's obviously only beneficial if they have the addressing...

...an only > happen with OS support and never happens within a single process on a > sane OS). > > This pass is more a matter of putting the IR in a form that precisely > matches the addressing modes that are actually available. AArch64 can > encode addresses like "base64 + sext(offset32)" into the actual > load/store instruction so it's advantageous to put the sext as close > as possible to the pointer dereference. > > I'm afraid I don't really know enough about other architectures to say > which could benefit. It's obviously only beneficial if...