similar to: [LLVMdev] MachO and ELF Writers/MachineCodeEmitters are hard-coded into LLVMTargetMachine

> Currently, the MachO and ELF Writers and MachineCodeEmitters are > hard-coded into LLVMTargetMachine and llc. I am also interested in working on this area and interested in writting a COFF file backend. > In other words, the 'object file generation' capabilities of the > Common Code Generator are not generic. I was looking at making a parallel class to MachineCodeEmitter,

I like the idea of a generic MachineCodeWriter, although I prefer the name 'ObjectFileWriter'... I think we need to take a hard look at which bits of the Writer/Emitter infrastructure are needed for what tasks (Object File Emittion, JIT, etc.) and make sure that our abstractions are flexible enough... As it stands at the moment, the Writer and Emitter classes could definately be merged

>I like the idea of a generic MachineCodeWriter, although I prefer the >name 'ObjectFileWriter'... Thats much more descriptive of the functionality. >I think we need to take a hard look at which bits of the >Writer/Emitter infrastructure are needed for what tasks (Object File >Emittion, JIT, etc.) and make sure that our abstractions are flexible >enough... I would

On Sun, Mar 15, 2009 at 10:52 PM, Aaron Gray < aaronngray.lists at googlemail.com> wrote: > I like the idea of a generic MachineCodeWriter, although I prefer the >> name 'ObjectFileWriter'... >> > > Thats much more descriptive of the functionality. > Sorry, I disagree actually the MachineCodeEmitter or the 'MachineCodeWritter' does not do any file

On Mon, Mar 16, 2009 at 3:26 AM, Aaron Gray <aaronngray.lists at googlemail.com > wrote: > On Sun, Mar 15, 2009 at 10:52 PM, Aaron Gray < > aaronngray.lists at googlemail.com> wrote: > >> I like the idea of a generic MachineCodeWriter, although I prefer the >>> name 'ObjectFileWriter'... >>> >> >> Thats much more descriptive of

> Sorry, I disagree actually the MachineCodeEmitter or the > 'MachineCodeWritter' does not do any file handling at all. Do look at the > code for the MachineCodeWritter and you will see it only writes to memory > and if it reaches the end of the allotted memory I believe higher ordered > logic reallocates a larget buffer and starts again from scratch. This could > be

> Sorry, I disagree actually the MachineCodeEmitter or the > 'MachineCodeWritter' does not do any file handling at all. Do look at the > code for the MachineCodeWritter and you will see it only writes to memory > and if it reaches the end of the allotted memory I believe higher ordered > logic reallocates a larget buffer and starts again from scratch. This could > be

Aaron, I mailed in the same mail twice (by mistake), you answered both copies. Differently! In any case, I've re-read what exists. I'm dumping what I understand here, so that we can discuss in detail. I'm using MachO as the example object format, as the ELF code is totally broken and outdated. Lets use the following as the basis for our discussion? There are 3 classes which

>> Sorry, I disagree actually the MachineCodeEmitter or the >> 'MachineCodeWritter' does not do any file handling at all. Do look at the >> code for the MachineCodeWritter and you will see it only writes to memory >> and if it reaches the end of the allotted memory I believe higher ordered >> logic reallocates a larget buffer and starts again from scratch.

> I've never looked at the MachO code as I do not have such a platform nor do > I know the file format. > > Could we concentrate on the ELF backend, please. I don't mind using the ELF backend as our test case, it just seems that the ELFWriter/ELFCodeEmitter don't even use the BufferBegin/BufferEnd/CurBufferPtr system exposed by the base MachineCodeEmitter. There is a big

> Aaron, I mailed in the same mail twice (by mistake), you answered both > copies. Differently! > > In any case, I've re-read what exists. I'm dumping what I understand > here, so that we can discuss in detail. I'm using MachO as the example > object format, as the ELF code is totally broken and outdated. Lets > use the following as the basis for our discussion?

Hi, I'm experimenting with using LLVM to generate dynamic FFI bridges in VisualWorks Smalltalk. LLVM is an amazing thing! I'm going from dynamically generated assembler source to machine code, and I have that all working, copied from the llc tool and the JIT example. I have two questions: 1. What optimization passes, if any, should I run on the module before I pass it to the

the reason I built llvm with vc is that I am familiar with vc. At first i also thing that build llvm with MingW will solve this problem. but after I read the source code void JITDebugRegisterer::RegisterFunction(const Function *F, DebugInfo &I) { // TODO: Support non-ELF platforms. if (!TM.getELFWriterInfo()) return; ...... } I thing MinGW is helpless with debug jit on win.

Hi everyone, I'm working in a company to port LLVM on their own processors. I'm try to support several set of instructions and several architectures. I'm using the "--target" options to choose my set of instructions, and I would like to use the "-mcpu" to choose the architecture of which I want to compile the code. Does it seem right? But at the moment I cannot

The distinction between the LLVMTargetMachine and TargetMachine classes has become somewhat muddy recently. So I created: https://reviews.llvm.org/D38482 to clean things up. During review it was noted that we may rather merge the two instead which looks like this: https://reviews.llvm.org/D38489 <https://reviews.llvm.org/D38489> We really should choose one of the two over the status quo.

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi > Amini via llvm-dev > Sent: Friday, January 06, 2017 11:10 AM > To: Sumanth Gundapaneni > Cc: LLVM Developers > Subject: Re: [llvm-dev] LLVMTargetMachine with optimization level passed > from clang. > > > > On Jan 6, 2017, at 10:56 AM, Sumanth

so as you said , there is no hop for debug jit on windows? 2011/6/7 ��f�� <chenwj at iis.sinica.edu.tw>: > Hi, Tang > >> but in the source code i find this comment. >> // ELF is a reasonably sane default and the only other X86 targets we >> // support are Darwin and Windows. Just use "not those". > > I guess you found above comment in

> so as you said , there is no hop for debug jit on windows? I have no idea. Maybe someone familiar with LLVM on Windows can answer your question. But I have a question for you, you said you built LLVM with Visual Studio and debugged your program with GDB. I doubt the Visual Studio produces the debugging information recognized by GDB. Why not build LLVM with MinGW or someting like that?

On Tue, Oct 3, 2017 at 8:54 AM Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 10/02/2017 10:57 PM, Matthias Braun via llvm-dev wrote: > > The distinction between the LLVMTargetMachine and TargetMachine classes > has become somewhat muddy recently. So I created: > > https://reviews.llvm.org/D38482 > > to clean things up. During review it was

I see the BackendUtil.cpp of Clang creates the TargetMachine with the optimization level based on below mentioned logic CodeGenOpt::Level OptLevel = CodeGenOpt::Default; switch (CodeGenOpts.OptimizationLevel) { default: break; case 0: OptLevel = CodeGenOpt::None; break; case 3: OptLevel = CodeGenOpt::Aggressive; break; } As per my understanding, the correspondence between