search for: r1026

...vide pretty cleanly between than and LiveIntervals. Beyond that, one of the issues is the "r2rmap" and "rep" function. As you've noticed, the coallescer basically uses these to avoid rewriting the code after it does coallescing. For example, if r1024 is coallesced with r1026, it leaves all uses of both registers in the code, instead of rewriting uses of r1026 with r1024 and deleting all memory of r1026. This mades sense long ago, but now it is increasingly clear that this is a bad idea. I would much rather have the coallescer be responsible for updating the code....

...k about the various algorithms? > Beyond that, one of the issues is the "r2rmap" and "rep" function. As > you've noticed, the coallescer basically uses these to avoid rewriting the > code after it does coallescing. For example, if r1024 is coallesced with > r1026, it leaves all uses of both registers in the code, instead of > rewriting uses of r1026 with r1024 and deleting all memory of r1026. This > mades sense long ago, but now it is increasingly clear that this is a bad > idea. I would much rather have the coallescer be responsible for updat...

...dition. I am having hard time mapping LLVM add to my machine add instruction based on the oprand types. Here is the sample code: void myFunction( int* src, int* dst, int i ) { dst[i] = src[i]; i = i + 4; return; } I want to get this translate to my machine code as following: shl R1028, R1026, 2 add_pointer R1029, R1024, R1028 // incrementing the src pointer load R1030, R1029 add_pointer R1031, R1025,R1028 // calculating the dst address store R1030, R1031 mov R1031, 4 add R1032, R1026, R1031 //scalar addition ret Currently my ADD instruction is defined in the InstrInfo.td file as f...

Hi all, As I work toward improving LLVM register allocation, I've come across the need to do some refactoring. Specifically, I would like to separate register coalescing from live interval analysis. Right now LiveIntervals handles both. The reason I want to separate them is that other types of register allocators might like to do coalescing differently (e.g. graph coloring does it by

...David Greene wrote: >> Beyond that, one of the issues is the "r2rmap" and "rep" function. As >> you've noticed, the coallescer basically uses these to avoid rewriting the >> code after it does coallescing. For example, if r1024 is coallesced with >> r1026, it leaves all uses of both registers in the code, instead of >> rewriting uses of r1026 with r1024 and deleting all memory of r1026. This >> mades sense long ago, but now it is increasingly clear that this is a bad >> idea. I would much rather have the coallescer be responsible...

...nd that, one of the issues is the "r2rmap" and "rep" >> function. As >> you've noticed, the coallescer basically uses these to avoid >> rewriting the >> code after it does coallescing. For example, if r1024 is >> coallesced with >> r1026, it leaves all uses of both registers in the code, instead of >> rewriting uses of r1026 with r1024 and deleting all memory of >> r1026. This >> mades sense long ago, but now it is increasingly clear that this >> is a bad >> idea. I would much rather have the coal...

...dition. I am having hard time mapping LLVM add to my machine add instruction based on the oprand types. Here is the sample code: void myFunction( int* src, int* dst, int i ) { dst[i] = src[i]; i = i + 4; return; } I want to get this translate to my machine code as following: shl R1028, R1026, 2 add_pointer R1029, R1024, R1028 // incrementing the src pointer load R1030, R1029 add_pointer R1031, R1025,R1028 // calculating the dst address store R1030, R1031 mov R1031, 4 add R1032, R1026, R1031 //scalar addition ret Currently my ADD instruction is defined in the InstrInfo.td file as f...

...xtend (e.g. i16 -> i8) wants to make use of subregisters. Consider code like this: t1 = load i16 t2 = truncate i16 t1 to i8 t3 = add i8 t2, 42 What we would really want to generate is something like this at the machine instr level: r1024 = X86_LOADi16 ... ;; r1024 is i16 r1026 = ADDi8 r1024[subreg #0], 42 More specifically, we want to be able to define, for each register class, a set of subregister classes. In the X86 world, the 64-bit register classes could have subregclass0 = i8 parts, subregclass1 = i16 parts, subregclass2 = i32 parts. Each <physreg, subreg#&...

...to this more and there is a part where I'm working with physical registers. If there is a function call, there is a copy from virtual register space to the functions that are expected to be passed into the register. So it looks something like this: ... do some work ... Mov %r0, %r1025 Mov %r1, %r1026 Mov %r2, %r1027 Call someFunc %r0, %r1, %r2 <-- this func stores to memory Ret The moves to the physical registers are being deleted as NonAllocatableRegs is set to all one's and then inverted, and since these are deleted, every instruction that they depended on is also deleted. I have a w...

On Apr 23, 2007, at 1:43 PM, Christopher Lamb wrote: > On Apr 23, 2007, at 1:17 PM, Christopher Lamb wrote: > >> On Apr 23, 2007, at 12:31 PM, Chris Lattner wrote: >> >>> On Mon, 23 Apr 2007, Christopher Lamb wrote: >>>> How can one let the back end know how to insert and extract >>>> elements of >>>> a vector through sub-register

...previous functions. For example: start function 0 r1024 = mov %var0.0 r1025 = mov %var0.1 lots of intermediate code call function1 w/ 3 parameters more intermediate code %r1300 = add %call.result, %r1024 end function 0 start function 1 %r1024 = mov %var1.0 %r1025 = mov %var1.1 %r1026 = mov %var1.2 some code return some value end function 0 The mov to r1024 in function 1 clobbers the data from function 0. The only ways I can think to get around this, is to push every virtual register used in a function to a stack or some internal data structure and then pull them back out...

...ading the machine instructions. EAX and all other > A registers are last used at instruction 40 and EAX is not defined > again > until instruction 48, which is the last use of register 1027. The > move to > register 1026 is entirely unnecessary -- why is it even there? Move to r1026 is marked dead. This is the artifact of translating CopyFromReg (of the call result) of EAX. It's harmless. EAX,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2 at 50 RAX,inf = [34,50:0)[50,54:1) 0@? 1 at 50 %reg1026,0 = [42,43:0) 0 at 42 %reg1027,0 = [46,50:0) 0@? 40 %reg1026<dead&gt...

No, there isn't something like that right now. What are you trying to accomplish? If you wish to implement this, it shouldn't be hard to do. Right now, MachineRegisterInfo re-starts virtual register number at TargetRegisterInfo::FirstVirtualRegister. You can add a mechanism to change that to a variable instead. Evan On Oct 20, 2008, at 1:43 PM, Villmow, Micah wrote: > Is

...to this more and there is a part where I'm working with physical registers. If there is a function call, there is a copy from virtual register space to the functions that are expected to be passed into the register. So it looks something like this: ... do some work ... Mov %r0, %r1025 Mov %r1, %r1026 Mov %r2, %r1027 Call someFunc %r0, %r1, %r2 <-- this func stores to memory Ret The moves to the physical registers are being deleted as NonAllocatableRegs is set to all one's and then inverted, and since these are deleted, every instruction that they depended on is also deleted. I have a w...

For the x86-64 target, I tried compiling a simple hello world. I don't understand the live interval information. Here's the machine instructions as dumped by LiveIntervalAnalysis: ********** MACHINEINSTRS ********** file hello.c line 3 b: 0 FNSTCW16m <fi#0>, 1, %NOREG, 0 FNSTCW16m <fi#0> 1 %mreg(0) 0 4 MOV8mi <fi#0>, 1, %NOREG, 1, 2 MOV8mi <fi#0> 1 %mreg(0) 1 2 8

Is there currently a way to have virtual register allocation information be saved across functions so that if I create a new virtual register in a function that it doesn't use a virtual register allocated in any previous function? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054

On Nov 18, 2008, at 11:24 AM, Villmow, Micah wrote: > Is there a way to tell LLVM to treat Boolean results as 32bit values > instead of 1 bit values? LLVM IR doesn't have a concept of C level booleans. What problem are you trying to solve? -Chris > > Thanks, > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices

...when it hits my backend, there are some changes that generate something weird. int gID = width; const int idx = gID % 64; const int idy = gID / 64; pv[gID] = 0; if( idy > 63 && idx > 0 ) { pv[gID]=1; } generates conditionals : ult r1043.x, 63, r1026.x ilt r1041.x, r1039.x, 1 and r1041.x, r1041.x, r1043.x if_logicalz r1041.x //write to pv endif which is C for if ((63 < idy && idx < 1) == 0) { } I have no clue how the 1 gets put in there but being able to sto...

Is there a way to tell LLVM to treat Boolean results as 32bit values instead of 1 bit values? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Apr 14, 2010, at 1:55 PMPDT, Villmow, Micah wrote: > I’ve recently sync’d to a newer version of LLVM(Apple branch 2326 from Apple branch 2323.8) that changed the interface to addCommonCodeGenPasses which caused the default implementation to be executed instead of my overriding implementation. This default implementation has DeadMachineInstructionElim pass enabled, which is causing havoc