similar to: [LLVMdev] Eliminating General Purpose Register

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

On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > 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

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Tuesday, March 26, 2013 12:40:44 PM > Subject: Re: [LLVMdev] [PATCH]

On Apr 6, 2013, at 12:42 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> >> To: "Akira Hatanaka" <ahatanak at gmail.com> >> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> >>

On Aug 3, 2010, at 3:12 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > >> 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 >>

hi zhu, i am not sure if your c frontend support "int ADC asm("GPR13");" i think you could: 1. add a attribute "GPR13"(or a more meaningful name like "adcreg") and the corresponding handler, so you code "int ADC asm("GPR13");" became "int ADC __attribute__((GPR13));" 2. add a intrinsic functions like

Hello everyone, I noticed that there are several register classes defined in X86 target and many of them are overlapping. Is there a list of all X86 register classes documented somewhere? I found many listed in X86GenRegisterInfo.inc(generated by tablegen) but unsure if that is the complete list. Also, is there documentation on the role and purpose of these classes and how the X86 backend decides

or you can just add a built-in function in c frontend "readadcreg()" and emit it as llvm.zhu.readadcreg(), so you can just call the built-in function to get the adc register value. On 2010-1-4 21:27, Demon(Xiangyang) Zhu 朱向阳 wrote: > Hi Ether, > > Thank you very much. I will try it soon as your description. > > Regards > > ________________________________________

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Akira Hatanaka" <ahatanak at gmail.com> > Sent: Saturday, April 6, 2013 11:56:28 AM > Subject: Re: [LLVMdev] [PATCH]

Hi everyone, There are 16 GPRs in my RISC, but in fact GPR13 is read-only and connected to output of an A/D converter. It would be very convenient if i could bind a register variable with GPR13. Because i am a newbie i don't know how my llvm backend can support that. I plan to implement it as below. A. first declare a global variable in c-code int ADC asm("GPR13"); B. If

Hello Matthias, On 28 July 2017 at 04:13, Matthias Braun <mbraun at apple.com> wrote: > It's not that hard in principle: > - A register class is a set of registers. > - Virtual Registers have a register class assigned. > - If you have register constraints (like x86 8bit operations only work on > al,ah,etc.) then you have to create a new register class to express that.

> On 12 Oct 2016, at 09:34, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Wed, Oct 12, 2016 at 1:23 AM David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 12 Oct 2016, at 07:29, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > > > I'm generally favorable on the core idea of having a type-safe and

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:

On 12 Oct 2016, at 07:29, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm generally favorable on the core idea of having a type-safe and friendly format-string-like formatting utility I’m also generally in favour, but I wonder what the key motivations for designing our own, rather than importing something like FastFormat, fmtlib, or one of the other

I am convinced to use llvm-gcc. As I mentioned in my previous email, I have changed native code generation in llc to generate code with a different stack organization. In order 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

Looking around today, it appears that TargetRegisterClass and MCRegisterClass only includes a single alignment. This is documented 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

> > How about a default GetInstSize() as well? Return 1 for every > instruction except for some special TargetInstrInfo instructions, e.g. > PHI, IMPLICIT_DEF, LABEL. I don't know 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

Hi, I see a lot of command line options being set in Target backend libraries. The problem with that is if a third party tool links 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

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.

Thank you all for your suggestions! @David, thanks for the advice, I'll check MCOptions again and look into LLVMContext. @Craig, @Aaron, great suggestion, moving the option away from CommandFlags.inc to a more appropriate file and adding an extern declaration to the corresponding header gives me more flexibility and allows me to invoke the option by using -mllvm. From my current