similar to: TargetMachine vs LLVMTargetMachine

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

Currently, the MachO and ELF Writers and MachineCodeEmitters are hard-coded into LLVMTargetMachine and llc. In other words, the 'object file generation' capabilities of the Common Code Generator are not generic. LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the derived backend TargetMachine implements one of getMachOWriterInfo or getELFWriterInfo, and returns a

> 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,

> -----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

Here is a problem scenario. I want to enable a backend pass at -O2 or above. if (TM->getOptLevel() >= CodeGenOpt::Default) addPass(&xxxxx); This pass will be run at -O1 too since clang is creating the TargetMachine with CodeGenOpt::Default for -O1. --Sumanth G -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Friday, January 6, 2017

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

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

getOptLevel() gets the level from TargetMachine which is created by the Backendutil in clang with either "Default", "None" or "Aggressive". Threre is no correspondence for "Less". This boils down to , if I pass "-O1", the Target Machine is created with CodeGenOpt::Default. I am available on IRC @ sgundapa. -----Original Message----- From:

Hi, I found some different discrepancy on how Subtarget is created between some arch specific TargetMachine constructor. For example, for BPF/Lanai: BPFTargetMachine::BPFTargetMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options,

Hi all, As of r232885 I've removed the argument-less TargetMachine::getSubtarget and TargetMachine::getSubtargetImpl. For the targets that aren't completely independent of this I've gone ahead and left a non-virtual version of the function in the target specific TargetMachine. What this means in practice is that those targets can only use a bare getSubtarget call in their target

I want the optimization to be turned on at -O1 and above. In my case, it is a target independent back-end pass. (Eg: MachinePipeliner) On 2017-01-04 18:10, Mehdi Amini wrote: >> On Jan 4, 2017, at 4:03 PM, Sumanth Gundapaneni via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> I see the BackendUtil.cpp of Clang creates the TargetMachine with >> the

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

>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

Chris Lattner wrote: > On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: > >>>> New method of emitting object code is ok for me. But it is still >>>> experimental, isn't it? >>> Yes. >> Thank you for answers! >> >> Now there is a way to implement what I'd like to. But it would be MUCH >> better if

Thanks, Alex. See my comments below. On Wed, Aug 23, 2017 at 12:59 AM, Alex Bradbury <asb at asbradbury.org> wrote: > On 22 August 2017 at 23:39, Y Song via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi, > > Hi Yonghong. > >> I found some different discrepancy on how Subtarget is created >> between some arch specific TargetMachine constructor.

Dear LLVM, Might be a easy question for someone, but not for me now. Consider there is a TargetMachine instance. Having this target, how could you get a corresponding Mangler class instance? Mangler depends on MCContext, which is connected with LLVMTargetMachine inherited from TargetMachine. However, LLVMTargetMachine is only available for targets machines implementations, and not available

On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >>> >>> New method of emitting object code is ok for me. But it is still >>> experimental, isn't it? >> >> Yes. > > Thank you for answers! > > Now there is a way to implement what I'd like to. But it would be MUCH > better if LLVMTargetMachine::addPassesToEmitFile could take

Chris Lattner wrote: > On Mar 27, 2010, at 11:56 AM, Peter Shugalev wrote: > >>>> What exactly is expected to be coming? Will it be the same way MachO is >>>> currently implemented but with some flexibility to supply my own class >>>> to do actual object output? Or just a return of old ObjectCodeEmitter? >>> We're integrating a full assembler

Hi, Just realized that ability to generate static object code (e.g. ELF w/o using JIT) is no longer available in 2.7 (at least in release_27 branch). For example > llc -filetype=obj whatever.bc doesn't work in Linux environment anymore (well it wasn't fully implemented before but it worked for simple bytecodes in 2.6). I used to generate code by creating TargetMachine and

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]