search for: x86registerinfo

In the X86RegisterInfo.td file, RST is defined like this: // Floating point stack registers (these are not allocatable by the // register allocator - the floating point stackifier is responsible // for transforming FPn allocations to STn registers) def RST : RegisterClass<"X86", [f64], 32,...

...to have working binaries, the libraries must be compiled with the new tool and have the same stack organization. Now that I cannot use llc, it seems that I have to modify llvm-gcc to have it generate code with the stack organization that I want. For X86 target I have particularly changed X86RegisterInfo::eliminateFrameIndex, X86RegisterInfo::emitPrologue and X86RegisterInfo::emitEpilogue in the llc source code. Can I find equivalent functions in the llvm-gcc source, so that I can implement the needed stack organization? Thank you, Babak On May 9, 2007, at 12:47 PM, Reid Spencer wrote: &gt...

...al and Ada need those too. 2.) The version 2.0 of your source code does not compile with Microsoft Visual C++ 2005 Express Edition. (By the way, is it documented that I need Bison? I figured that out myself...): ------ Build started: Project: x86, Configuration: Release Win32 ------ Compiling... X86RegisterInfo.cpp ..\..\lib\Target\X86\X86RegisterInfo.cpp(1107) : warning C4244: 'argument' : conversion from 'uint64_t' to 'int', possible loss of data ..\..\lib\Target\X86\X86RegisterInfo.cpp(1127) : warning C4244: 'argument' : conversion from 'uint64_t' to 'int'...

...w if it's useful or not. But > perhaps we can default most targets to it? > > I prefer not giving a default implementation and aborting with a message that says the target did not implement it. This way we know why it's not working. Is it OK? >> // >> -unsigned X86RegisterInfo::getX86RegNum(unsigned RegNo) const { >> +unsigned X86RegisterInfo::getX86RegNum(unsigned RegNo) { >> > > What happened to "const"? > I made the function static. >> + unsigned Size = GetInstSizeWithDesc(*MI, &Desc, IsPIC, >> Is64BitMode);...

I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: _main: pushq %rbp Ltmp18: movq %rsp, %rbp Ltmp19: subq $320, %rsp Ltmp20: movl %ecx, -276(%rbp) I've tracked them back to emitPrologue in X86RegisterInfo.cpp. I'm wonder what's their purpose? They're filling up my symbol table... Cameron Esfahani dirty at apple.com "All that is necessary for the triumph of evil is that good men do nothing." Edmund Burke

Hi all, I cannot figure out why is named GenRegisterInfo.h.inc and not GenRegisterInfo.inc ... Is it for a dependency problem? Back again to compilation problems under win32 with VC llvm\lib\Analysis\DataStructure\Local.cpp(628) : error C2105: '--' needs l-value the line is: Result.mergeWith(getValueDest(**--CS.arg_end())); Can I submit patches for mutate it in something like:

...igure out why is named GenRegisterInfo.h.inc and not > GenRegisterInfo.inc ... > Is it for a dependency problem? I'm not sure what you're saying here. In the X86 backend, for example, we generate both X86GenRegisterInfo.h.inc and X86GenRegisterInfo.inc. The former is #included into X86RegisterInfo.h and the latter is #included into X86RegisterInfo.cpp. Does this make sense? They are both correct. > Back again to compilation problems under win32 with VC > > llvm\lib\Analysis\DataStructure\Local.cpp(628) : error C2105: '--' needs > l-value > > the line is: > &gt...

...as being the minimum legal alignment, but it appears to often be greater than this in practice. For instance, on x86 the alignment of %ymm0 is listed as 32, not 1. Does anyone know why this is? Additionally, where are these alignments actually defined? I don't seem them appearing in the X86RegisterInfo.td files as I would naively expect. The background for my question is that I'm looking into adding a function attribute which uses unaligned loads and stores for register spilling on x86 to avoid the need for dynamic frame realignment. (see the previous thread "Aligned vector spills a...

...all > > could LLVM do that for me, using the system stack, (not continuations with > malloc)?  Or am I barking up the wrong tree with this tool? Messing with the prologue and epilogue should be feasible, although you'll have to modify the code, and it's very platform-specific; see X86RegisterInfo::emitPrologue in lib/Target/X86/X86RegisterInfo.cpp in the source tree. -Eli

...inks with Target libraries and has a command line option that needs to be processed, the option in the Target libraries will get overridden. $ cd llvm/lib/Target $ grep 'cl::' */*.cpp --> produces lot of such occurences. For example :- libLLVMX86CodeGen.a contains libLLVMX86CodeGen.a:X86RegisterInfo.cpp.o:0000000000000080 b EnableBasePointer I think those command line options would need to be moved to the drivers that are using them, Isnt it ? Am I mistaken ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

...015 03:59 PM, Matthias Braun wrote: > Looks to me like the alignment is specified in tablegen. From Target.td: > > class RegisterClass<string namespace, list<ValueType> regTypes, int alignment, > dag regList, RegAltNameIndex idx = NoRegAltName> > > X86RegisterInfo.td: > > def VR256 : RegisterClass<"X86", [v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], > 256, (sequence "YMM%u", 0, 15)>; > def VR256X : RegisterClass<"X86", [v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], >...

...ding an extern declaration to the corresponding header gives me more flexibility and allows me to invoke the option by using -mllvm. From my current understanding, adding a function attribute would not be sufficient, since I need to query the option unrelated to functions, e.g. as early as when the X86RegisterInfo constructor is called. As of now, I'm not aware of any mechanism within the codebase that would allow me to do so, but perhaps you can point out something. Thanks again Oskar > Aaron Smith <aaron.lee.smith at gmail.com> hat am 6. Januar 2020 um 23:06 geschrieben: > > > Def...

...rgets to it? >> >> > > I prefer not giving a default implementation and aborting with a > message > that says the target did not implement it. This way we know why it's > not > working. Is it OK? That's ok. > > >>> // >>> -unsigned X86RegisterInfo::getX86RegNum(unsigned RegNo) const { >>> +unsigned X86RegisterInfo::getX86RegNum(unsigned RegNo) { >>> >> >> What happened to "const"? >> > > I made the function static. Ok. > > >>> + unsigned Size = GetInstSizeWithDesc(*MI, &am...

...g some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: > > _main: > pushq %rbp > Ltmp18: > movq %rsp, %rbp > Ltmp19: > subq $320, %rsp > Ltmp20: > movl %ecx, -276(%rbp) > > I've tracked them back to emitPrologue in X86RegisterInfo.cpp. I'm wonder what's their purpose? > > They're filling up my symbol table... EH ranges for unwind info. If you look later on in the file for the symbols you'll see them. -eric

...asmwriternum seems to be not supported... scons: Building targets ... d:/home/arathorn/sandbox/llvm/tblgen.exe -gen-asm-writer -asmwriternum=1 -I llvm\lib\Target\X86 -o tablegen_includes\X86GenIntelAsmWriter.inc llvm\lib\Target\X86\X86.td llvm\lib\Target\X86\X86InstrInfo.td llvm\lib\Target\X86\X86RegisterInfo.td llvm\lib\Target\Target.td d:/home/arathorn/sandbox/llvm/tblgen.exe: Unknown command line argument '-asmwriternum=1'. Try: 'd:/home/arathorn/sandbox/llvm/tblgen.exe --help' 2) related to previous problem? scons: Building targets ... d:/home/arathorn/sandbox/llvm/tblgen.exe -ge...

...s after printing "B". The generated > assembler code looks reasonable at a first glance, It shouldn't. At least all frame moves information is missing. > but something must be broken. Any ideas about how to debug this? I'd suggest to start with filling necessary bits in the X86RegisterInfo.cpp. This includes frame moves information and description of stack layout. Then you can proceed to x86-64-specific lowering of some important intrinsics. You can link your code with native g++ in order to use gcc-provided (and thus working) runtime. -- WBR, Anton Korobeynikov

...lt;std::iterator<std::bidirectional_iterator_tag, llvm::MachineInstr, long int, llvm::MachineInstr*, llvm::MachineInstr&>> = {<No data fields>}, NodePtr = 0x4b69440}, DL={LineCol = 0, ScopeIdx = 0}, TID=@0x803a78940) at MachineInstrBuilder.h:183 #3 0x0000000803451825 in llvm::X86RegisterInfo::emitPrologue (this=0x1a96220, MF=@0x30eb000) at /tmp/llvm-svn/llvm/lib/Target/X86/X86RegisterInfo.cpp:1037 #4 0x0000000802cdf3e5 in llvm::PEI::insertPrologEpilogCode (this=0x3231900, Fn=@0x30eb000) at /tmp/llvm-svn/llvm/lib/CodeGen/PrologEpilogInserter.cpp:680 #5 0x0000000802cdcf04 in llvm::...

...t;std::bidirectional_iterator_tag, llvm::MachineInstr, > long int, llvm::MachineInstr*, llvm::MachineInstr&>> = {<No data > fields>}, NodePtr = 0x4b69440}, DL={LineCol = 0, ScopeIdx = 0}, > TID=@0x803a78940) at MachineInstrBuilder.h:183 > #3 0x0000000803451825 in llvm::X86RegisterInfo::emitPrologue > (this=0x1a96220, MF=@0x30eb000) at > /tmp/llvm-svn/llvm/lib/Target/X86/X86RegisterInfo.cpp:1037 > #4 0x0000000802cdf3e5 in llvm::PEI::insertPrologEpilogCode > (this=0x3231900, Fn=@0x30eb000) at > /tmp/llvm-svn/llvm/lib/CodeGen/PrologEpilogInserter.cpp:680 > #5 0x...

Hi As requested from Paolo, I've sent him the tablegen tool. The tool is able to compile the td files (given in the makefile) on windows without any complaints. Henrik >From: Paolo Invernizzi <arathorn at fastwebnet.it> >Date: Thu, 7 Oct 2004 14:27:11 +0200 > >Hi Henrik, > >As you may remember, I'm trying to use the LLVM core tools under Visual >Studio.

...r. > - /// > - unsigned GetInstSize(MachineInstr *MI); > - > - /// GetFunctionSize - Returns the size of the specified > MachineFunction. > - /// > - unsigned GetFunctionSize(MachineFunction &MF); > - } > } > > #endif > Index: lib/Target/X86/X86RegisterInfo.cpp > =================================================================== > --- lib/Target/X86/X86RegisterInfo.cpp (revision 49716) > +++ lib/Target/X86/X86RegisterInfo.cpp (working copy) > @@ -84,7 +84,7 @@ > // getX86RegNum - This function maps LLVM register identifiers to > t...