similar to: [LLVMdev] Codegen performance issue: LEA vs. INC.

This sounds like llvm.org/pr13320. On 17 September 2013 18:20, Bader, Aleksey A <aleksey.a.bader at intel.com> wrote: > Hi all. > > > > I’m looking for an advice on how to deal with inefficient code generation > for Intel Nehalem/Westmere architecture on 64-bit platform for the attached > test.cpp (LLVM IR is in test.cpp.ll). > > The inner loop has 11 iterations

The two address pass is only concerned about register pressure. It sounds like it should be taught about profitability. In cases where profitability can only be determined with something machinetracemetric then it probably should live it to more sophisticated pass like regalloc. In this case, we probably need a profitability target hook which knows about lea. We should also consider disabling

On Oct 2, 2013, at 11:48 PM, Evan Cheng <evan.cheng at apple.com> wrote: > The two address pass is only concerned about register pressure. It sounds like it should be taught about profitability. In cases where profitability can only be determined with something machinetracemetric then it probably should live it to more sophisticated pass like regalloc. > > In this case, we

Hi, Assume I define registers R0...R15 and two register classes RegA and RegB. RegA contains R0 to R7 while RegB contains R0 to R15. Then I check the machine instruction, it seems that in some cases, the %vreg0 belongs to RegB; in other cases %vreg1 belongs to RegA_RegB. Can you tell me how TableGen decides which is which? At first, I guess &verg0 will be assigned by R8 to R15 only so that

Hi, I'm trying to complete the lowering for a new microcontroller. I'm using LLVM 3.8. For now this lowering crashes on 'Store' node, which is actually not yet defined. I've tried to map the ISel 'Store' node to architecture specific instructions. I've define the following semantic to my architecture specific instructions: def MOVSUTO_SU_rr :

Hi, I'm having trouble using virtual register in the X86 backend. I implemented a new intrinsic and I use a custom inserter. The goal of the intrinsic is to set the content of the stack to zero at the end of each function. Here is my code: MachineBasicBlock * X86TargetLowering::EmitBURNSTACKWithCustomInserter( MachineInstr *MI, MachineBasicBlock

> > Thank you Chris. I will try to implement the TwoAddress pass to run on > > machine code. Why it has not been originally implemented to run on > > machine code? > > I'm not sure what you mean. It definitely does run on machine code. I was thinking that it only transformed instructions with virtual registers because of this code in the TwoAddressInstructionPass.cpp:

Hi, Thx for your help... Here is the IR code: ; ModuleID = 'foo_bar.c' target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @.str = private unnamed_addr constant [6 x i8] c"MAIN\0A\00", align 1 ; Function Attrs: nounwind uwtable define i32 @main(i32 %argc, i8** %argv) #0 { entry: %retval = alloca i32,

>-----Original Message----- >From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >Sanjoy Das via llvm-dev >Sent: Thursday, December 03, 2015 11:16 PM >To: Quentin Colombet <qcolombet at apple.com> >Cc: llvm-dev at lists.llvm.org >Subject: Re: [llvm-dev] analyzePhysReg question > >I think this is related to PR25033:

On Mon, 26 Jun 2006, Fernando Magno Quintao Pereira wrote: > Thank you Chris. I will try to implement the TwoAddress pass to run on > machine code. Why it has not been originally implemented to run on > machine code? I'm not sure what you mean. It definitely does run on machine code. > Is there anything that makes it troublesome after RA > has been performed? Do you

Thank you Chris. I will try to implement the TwoAddress pass to run on machine code. Why it has not been originally implemented to run on machine code? Is there anything that makes it troublesome after RA has been performed? Could you tell me if the transformations below are correct? 1) a := b op c --> a := b --> a := b a := a op c a

On 17.09.2013, at 20:04, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > Hi Andy, > > We have done some experimental evaluation of the different schedulers in LLVM 3.3 (source, BURR, ILP, fast, MI). The evaluation was done on x86-64 using SPEC CPU2006. We have measured both the amount of spill code as well as the execution time as detailed below. > > Here are our

Hello, Im back trying to finish my backend to a simple RISC cpu SABRE now that most of the tedious process of examining undergraduate students is out of the way. I have managed to describe the registers and the instructions in the architecture and have added support for 32 bit immediates (thanks to Christopher Lamb) as the instruction set only supports 17 bit immediates directly. Could

Hi Andy, We have done some experimental evaluation of the different schedulers in LLVM 3.3 (source, BURR, ILP, fast, MI). The evaluation was done on x86-64 using SPEC CPU2006. We have measured both the amount of spill code as well as the execution time as detailed below. Here are our main findings: 1. The SD schedulers significantly impact the spill counts and the execution times for many

> On Dec 3, 2015, at 5:36 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Dec 3, 2015, at 5:11 PM, Smith, Kevin B <kevin.b.smith at intel.com <mailto:kevin.b.smith at intel.com>> wrote: >> >> >> >>> -----Original Message----- >>> From: Quentin Colombet [mailto:qcolombet at apple.com

> I'll be happy to answer any further questions you may have, feel free to e-mail > me directly (though right now our mail server is down) > The salient features that we want to have in the driver are: 1. llvm-ld will be used as "The Optimizer". 2. If the user has specified to generate the final executable, then llvm-ld should run on all the .bc files generated by clang

Hi Sanjiv, Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes: > The salient features that we want to have in the driver are: > [...] As promised, I've implemented a basic compiler driver for the PIC16 toolchain. It's under tools/llvmc/examples/mcc16. Some examples illustrating the features you requested: > 2. If the user has specified to generate the final

Hi, Please see the two ".ll' files attached. Command line used llc -march=pic16 -pre-RA-sched=list-burr -regalloc=pbqp new.obc The above test case crashes only when I use the combination of list-burr scheduler and pbqp register allocator. If any of them (scheduler or register allocator) is replaced with some alternate then I don't see the crash. I could not figure

Thanks. I saw the header comments but it wasn’t clear to me what the difference between those concepts is? My slightly vague understanding is IsDef means that the register specified by this operand is set by the machine instruction. So I understand that to mean the MO will override that register? Also things like early clobber, perhaps there is another document that clarifies some of these

Hello, I'm working on the text of my Master's Thesis and I have some doubts: 1. What algorithm is used in Selection Instruction ? What is the input ? 2. Where is described how the variations of List Scheduling work, in -pre-RA-sched phase ? -pre-RA-sched - Instruction schedulers available (before register allocation): =source -