similar to: [LLVMdev] Move TargetRegisterInfo and TargetInstrInfo into libCodeGen

On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? > > TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen

On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >> >> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most

On Nov 27, 2012, at 11:51 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > >> On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >>> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen?

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

Hello LLVM Developers, We are working on extending currently available register rematerialization to include cases where sequence of multiple instructions is required to rematerialize a value. We had a discussion on this in community mailing list and link is here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/subject.html#104777 >From the above discussion and studying the code we

I have mixed feeling about this. While this does separate out target-independent pieces into CodeGen, it also introduces some confusion where the default implementation is in CodeGen while target overridden version are in Target. I also hate to see all these Target* classes being moved to CodeGen. I thought our solution to this issue is classes such as TargetInstrInfoImpl. What's wrong with

On Wed, Sep 11, 2013 at 12:29 AM, Andrew Trick <atrick at apple.com> wrote: > > If that is the goal, then you only want the modules for Machine IR, and maybe some core analysis passes. The “Machine” modules you listed above include machine code analysis or transform passes that you probably don’t want. Pruning the list to basic IR support: > >> - MachineBasicBlock >> -

We've had a circular dependency in LLVM for a while, and while we've been fortunate that we could ignore it by implementing functions in header files, a recent innocent change caused a cyclic dependency between Target and CodeGen just because of inlining that happens in GCC. I'm proposing to fix this by moving code from Target to CodeGen If I understand correctly, lib/CodeGen is

Nick Lewycky wrote: > We've had a circular dependency in LLVM for a while, and while we've > been fortunate that we could ignore it by implementing functions in > header files, a recent innocent change caused a cyclic dependency > between Target and CodeGen just because of inlining that happens in > GCC. I'm proposing to fix this by moving code from Target to CodeGen

I am considering adding a new target independent codegen-only COPY instruction to our MachineInstr representation. It would be used to replace INSERT_SUBREG, EXTRACT_SUBREG, and virtual register copies after instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer. The COPY instruction handles subreg operations with less

Hi All, I'm dealing with a problem where the spill/restore instructions inserted during scavenging span an adjustment of the SP/FP register. The result is that despite the base register (SP/FP) being changed between the spill and the restore, both store and load use the same immediate offset. I see code in the PEI (replaceFrameIndices) that is supposed to track the SP/FP adjustment:

On 12 December 2011 12:22, Evan Cheng <evan.cheng at apple.com> wrote: > I have mixed feeling about this. While this does separate out target-independent pieces into CodeGen, it also introduces some confusion where the default implementation is in CodeGen while target overridden version are in Target. I also hate to see all these Target* classes being moved to CodeGen. > > I thought

On Jun 15, 2010, at 2:48 PM, Jakob Stoklund Olesen wrote: > I am considering adding a new target independent codegen-only COPY instruction to our MachineInstr representation. It would be used to replace INSERT_SUBREG, EXTRACT_SUBREG, and virtual register copies after instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer.

Hi, In the context of MachineCode custom inserter, I'm trying to enforce the mapping of virtual register to a physical one. According to the documentation https://llvm.org/docs/CodeGenerator.html#mapping-virtual-registers-to-physical-registers There are two ways: the direct one and the indirect ones. The indirect ones refer VirtRegMap class that I've never found. So I tried the direct

Hi, I'm looking for some pointers on how to troubleshoot this problem. I'm trying to write a backend for the AVR. There is an undefined reference at line 48 which is the line FrameInfo() is on. I've tried to use the MSP430 and other targets as references so I'm not sure what changes I did would cause a problem on this line? AVRTargetMachine::AVRTargetMachine(const Target &T,

Hi, I did the Pass ID workaround by providing Passes.h in the include/llvm/Machine. But the question which is holding me up is that, as Ken Dyck was kind enough to point out, what should be done to the dependency on libAnalysis? The Machine passes are not only dependent on Passes class but also on others such as the ConstantFolding.h. Is it a possible solution to break this dependency or carry

On May 16, 2011, at 6:52 AM, Justin Holewinski wrote: > Currently, the TableGen register info files for all of the back-ends define concrete registers and divide them into logical register classes. I would like to get some input from the LLVM experts around here on how best to map this model to an architecture that does *not* have a concrete, pre-defined register file. The architecture is

Hi John, Thank you for the comments. I am addressing some of them bellow. Regards, Samuel 2014-08-11 9:36 GMT-04:00 John Leidel (jleidel) <jleidel at micron.com>: > Sergey [et.al], thanks for putting this proposal together. Overall, this > looks like a pretty solid approach to providing relatively hardware > agnostic omp target functionality. I had several comments/questions

CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. That means when the code is expected to be called before the pseudo instructions are eliminated. I don't know why it's not the case for you. A quick look at PEI code indicates the pseudo's should not have been removed at the time when replaceFrameIndices are run. Evan On Sep 25, 2013, at 8:57 AM, Krzysztof

Hi, I have a task to complete and I'm getting stuck. I can't find anything comparable in the documentation. The shortest explanation I can give is as follows: I need to use double-precision floating point values for floating-point multiplies. I'll not go into why: That would take the discussion away from the essential problem. E.g. Replace: fmuls %f20,%f21,%f8 with the