You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(26) |
Dec
(15) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(14) |
Oct
(16) |
Nov
(36) |
Dec
(3) |
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(17) |
May
(9) |
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(4) |
2012 |
Jan
(22) |
Feb
(12) |
Mar
(39) |
Apr
(31) |
May
(42) |
Jun
(35) |
Jul
(32) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(9) |
2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(121) |
Jul
(61) |
Aug
(7) |
Sep
(8) |
Oct
(6) |
Nov
|
Dec
(1) |
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Borja F. <bor...@gm...> - 2011-04-11 16:02:43
|
I would like to finish up the global load/store stuff before committing the new code. Also during the next week i'm going to be very very busy so i can't precisely say when it will happen, unless threre's some sort of big reason that requires to commit the code :) So i would say at the end of next week. As a side note, i've finished up working with predrecement loads/stores, so now it's time for lds/sts for real. 2011/4/10 Weddington, Eric <Eri...@at...> > > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Sunday, April 10, 2011 9:48 AM > > To: Weddington, Eric > > Cc: avr...@li... > > Subject: Re: [avr-llvm-devel] Status update > > > > Small update: > > Today I've finished introducing support for post-increment load and > > stores. Pre-decrement should be nearly copy paste with some small > changes. > > After this is done, i'll take a look at lds/sts as mentioned in a > previous > > email so we can load/store globals (only data memory at the moment). > > Thanks for doing this! What are your plans for committing your new work? > |
From: Weddington, E. <Eri...@at...> - 2011-04-10 17:15:52
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Sunday, April 10, 2011 9:48 AM > To: Weddington, Eric > Cc: avr...@li... > Subject: Re: [avr-llvm-devel] Status update > > Small update: > Today I've finished introducing support for post-increment load and > stores. Pre-decrement should be nearly copy paste with some small changes. > After this is done, i'll take a look at lds/sts as mentioned in a previous > email so we can load/store globals (only data memory at the moment). Thanks for doing this! What are your plans for committing your new work? |
From: Borja F. <bor...@gm...> - 2011-04-10 15:48:26
|
Small update: Today I've finished introducing support for post-increment load and stores. Pre-decrement should be nearly copy paste with some small changes. After this is done, i'll take a look at lds/sts as mentioned in a previous email so we can load/store globals (only data memory at the moment). John i will try renaming the clang folder since i'm working in linux. |
From: Weddington, E. <Eri...@at...> - 2011-04-08 23:29:34
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Tuesday, April 05, 2011 5:45 PM > To: Weddington, Eric > Cc: avr...@li... > Subject: Re: [avr-llvm-devel] Status update > > Hello Eric, I phrased that in a wrong way sorry :) Basically when i wrote > that movws were going to be emitted always i meant that they were going to > be emitted directly by the compiler and not manually inserted as it's > currently happening. The current implementation searches for 8 bit moves > and tries to transform 2 moves in a row to a single movw, but it's missing > many cases so that's why they dont get always emitted. With the new > implementation, since the compiler is emitting real 16bit moves we will > have a movw when it's needed so there's no danger of getting movws lost. Ah, ok. That makes more sense. Thanks for the clarification. <snip> > OFFTOPIC: During the past weeks i've been implementing a 4 stage pipelined > MIPS core in Verilog for an FPGA for a master class project, and now i > really have a good feeling of the beauty of what is inside the RISC cpus. > It's nice to have different point of views: the programmer, the compiler, > the CPU core hardware... Very cool! :-) Eric |
From: John M. <ato...@gm...> - 2011-04-06 02:37:29
|
On Tue, Apr 5, 2011 at 2:31 PM, Borja Ferrer <bor...@gm...> wrote: > PS: John do you get clang rebuilt each time you recompile LLVM, if that's > the case do you know a way to stop this because linking it takes like 40secs > here. Im using ccache as mentioned in some doc file. > No, if I remember correctly, mostly only the clang source files that have changed get compiled. I think certain LLVM library's cause parts of clang to be rebuild though. I remember working on some parts of LLVM would seem to cause the clang compilations to take a long time compared to when I would modify other files in LLVM. On Linux using *configure *I used to rename * tools/clang* which keeps the LLVM build system from trying to compile clang also. With CMake+VS you can disable compilation of each project separately. |
From: Borja F. <bor...@gm...> - 2011-04-05 23:44:46
|
Hello Eric, I phrased that in a wrong way sorry :) Basically when i wrote that movws were going to be emitted always i meant that they were going to be emitted directly by the compiler and not manually inserted as it's currently happening. The current implementation searches for 8 bit moves and tries to transform 2 moves in a row to a single movw, but it's missing many cases so that's why they dont get always emitted. With the new implementation, since the compiler is emitting real 16bit moves we will have a movw when it's needed so there's no danger of getting movws lost. About what you mentioned about other devices, indeed this is something that has to be done. I already kept this in mind, thinking about the tiny devices that lack mul, movw, and other instructions support, with 8 bit ptrs, and the largests that have 24?bit ptrs. LLVM has a very nice interface to handle this sort of stuff, so in theory it shouldnt be hard to implement, but really tedious. Basically, first you define a device model say the ATMEGA644PA and in there you can list its supported features, in x86 these features would be SSE1, SSE2, AVX, etc.. in our case we would have MUL, MOVW, ELPM and friends, support etc. Then when emitting the code we check if for example movw is supported for the current device, if it's not supported then LLVM has to take another path and emit a different instruction, or if for example the device doesnt have a builtin multiplier then either expand the mult instr into a chain of adds or make a libcall. I'm really interested in your help when we start supporting other devices to get things right and support every single device in the market. We'll need a good classification of the devices to list these features i mentioned so we can add them for every supported device. For the moment im focusing in the atmega644, which has a lots of features in its CPU core, and then for smaller devices we'll have to add restrictions as explained above to avoid illegal instructions getting emitted, and for larger devices ... well i cant talk about those for now because i've never worked with them. OFFTOPIC: During the past weeks i've been implementing a 4 stage pipelined MIPS core in Verilog for an FPGA for a master class project, and now i really have a good feeling of the beauty of what is inside the RISC cpus. It's nice to have different point of views: the programmer, the compiler, the CPU core hardware... |
From: Weddington, E. <Eri...@at...> - 2011-04-05 22:59:21
|
Wow! Thanks for the update! :-) I like what I'm hearing so far. The cons don't sound all that bad, considering the pros that you mentioned. It sounds to me that you're on the right track, but I'll be interested in what others have to say, too. My only caution comes from what you said about using movw always: There are avr chip variants that don't have a movw instruction. For that matter there are different instruction set variants that are dependent on the avr device type. AVR GCC sort-of handles this by organizing the list of chips into arbitrary "architectures", which are then associated with memory ranges and loosely based instruction sets. However, there always seems to be some exceptions to the rule. So my only advice to you is to keep this in mind and that we'll need to have some sort of mechanism to tie the avr device type with enabling/disabling specific instructions. I don't really care if we use a similar mechanism as AVR GCC with these arbitrary architectures. However, I would be fine too if we dropped the "architectures", because these are arbitrary and there are exceptions and sometimes they're more of a maintenance headache than it's worth. (As a side note, this is one area where I hope to help out in, though I still have quite a learning curve.) With this, also keep in mind that there is a relatively new AVR sub-family, based on the newly released ATtiny10 (all variants: ATtiny10/4/5/9/20/40). This is a weird family: - The register file is cut in half. It only has R16-R31, however R0-R15 still exist, they just map to the upper half of the register file. - Reduced instruction set. There are a number of disabled instructions (have to see datasheets for full list). - Really small amounts of flash (code), and even smaller amounts of RAM (data). Yet, with all of these limitations, there is still a desire to have a C compiler for these devices. The latest "AVR Toolchain" release from Atmel has support for these devices. Thanks again, Borja, for your work on this! I'm really excited to see your work committed! :-) Eric Weddington > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Tuesday, April 05, 2011 3:31 PM > To: avr...@li... > Subject: [avr-llvm-devel] Status update > > Hello, it's been a little while since last time we got an update. Although > I haven't commited any code during the last 3 months, I want to say that > doesn't mean the project is dead or something similar, it's just the > opposite that's why i want to explain what is the current status, in fact > i havent stopped working on this at all. > > From Jan to approximately March I've been investigating different ways to > handle the insane reg constraints to pair adjacent regs to store 16bit and > wider data with the PBQP allocator and other ideas i had, I think i had > like 4 branches to see which one was the best. From here I want to give a > big thank to Lang Hames, the author of this allocator for all the help he > gave me and for his interest. But solving this using this approach was > getting pretty hard, tracking which virtual reg had the low and hi part of > a 16bit value is simply impossible in LLVM with the current interfaces in > order to build the constraint matrix for the PBPQ allocator, in addition, > there were other underlying problems when working with only 8bit types as > a legal sizes, like 16 bit pointers. > > So around mid March I started a new backend from scratch with a new idea > which has simplified everything in a huge manner. Like everything in this > life, all things have pros and cons so we have to get a balance. The > biggest pro of this approach is it's simplicity, the cons is that we'll > have to work a bit harder to get some nice optimizations in. But these > cons aren't too bad at all, because most of them would have to be handled > in all aproaches so after all, we will have to get our hands dirty to get > really nice code. > The basic idea is to make 16bit data legal, that means working with pseudo > register pairs and psuedo 16 bit instructions that need to get expanded > into 8 bit instructions in a later stage. When we get a movw or adiw/sbiw > we leave them alone because they're legal instructions but when we get say > a 16bit and instr we have to expand it to two and instructions. As i said, > when we move further we can start thinking in introducing optimizations > over pseudo intrs which is something that gcc doesn't do very well, and > after all we want to beat it. > > So the current status is: > - Added support for all arithmetic and binary instructions for all data > types, except mul. Including, INC/DEC, COM/NEG and SWAP. > - Convert all (add x, imm) into sub(x, -imm) since we dont have an add > with imm instruction. This saves doing ldi+add into a subi. > - Handle adiw/sbiw instructions when it's beneficial. > - Allocate everything in register pairs, as it should be, and emit movw > always, no need for more heuristics. > - Implemented calling conventions, including argument passing, return > values, and function calls, including externals symbols which isn't > handled in the current backend in SVN. > - Pointers are now 16bits as it should be, and not 8bits as a hack. > - Added support for ICALL. > - BIG ONE: Added support for data memory operatons, this includes: ld, > ldd, st and std. This adds support for the reg+imm addressing mode when > imm<64. > - Print for ld, ldd, st and std when emmiting asm code the X, Y, Z names. > > I think this is it for the moment, probably i've left something out, but > those are the basic points. I'm currently working in adding support for > lds and sts, so we can load/store global symbols. And after that is > implemented we'll be able to implement stack frames, which is an important > milestone. > I'll commit the new code in a few days, i want to get something done > before. Let me know your thoughts. For me the most important part is to > remark that we're moving further. > > PS: John do you get clang rebuilt each time you recompile LLVM, if that's > the case do you know a way to stop this because linking it takes like > 40secs here. Im using ccache as mentioned in some doc file. |
From: Borja F. <bor...@gm...> - 2011-04-05 21:31:07
|
Hello, it's been a little while since last time we got an update. Although I haven't commited any code during the last 3 months, I want to say that doesn't mean the project is dead or something similar, it's just the opposite that's why i want to explain what is the current status, in fact i havent stopped working on this at all. >From Jan to approximately March I've been investigating different ways to handle the insane reg constraints to pair adjacent regs to store 16bit and wider data with the PBQP allocator and other ideas i had, I think i had like 4 branches to see which one was the best. From here I want to give a big thank to Lang Hames, the author of this allocator for all the help he gave me and for his interest. But solving this using this approach was getting pretty hard, tracking which virtual reg had the low and hi part of a 16bit value is simply impossible in LLVM with the current interfaces in order to build the constraint matrix for the PBPQ allocator, in addition, there were other underlying problems when working with only 8bit types as a legal sizes, like 16 bit pointers. So around mid March I started a new backend from scratch with a new idea which has simplified everything in a huge manner. Like everything in this life, all things have pros and cons so we have to get a balance. The biggest pro of this approach is it's simplicity, the cons is that we'll have to work a bit harder to get some nice optimizations in. But these cons aren't too bad at all, because most of them would have to be handled in all aproaches so after all, we will have to get our hands dirty to get really nice code. The basic idea is to make 16bit data legal, that means working with pseudo register pairs and psuedo 16 bit instructions that need to get expanded into 8 bit instructions in a later stage. When we get a movw or adiw/sbiw we leave them alone because they're legal instructions but when we get say a 16bit and instr we have to expand it to two and instructions. As i said, when we move further we can start thinking in introducing optimizations over pseudo intrs which is something that gcc doesn't do very well, and after all we want to beat it. So the current status is: - Added support for all arithmetic and binary instructions for all data types, except mul. Including, INC/DEC, COM/NEG and SWAP. - Convert all (add x, imm) into sub(x, -imm) since we dont have an add with imm instruction. This saves doing ldi+add into a subi. - Handle adiw/sbiw instructions when it's beneficial. - Allocate everything in register pairs, as it should be, and emit movw always, no need for more heuristics. - Implemented calling conventions, including argument passing, return values, and function calls, including externals symbols which isn't handled in the current backend in SVN. - Pointers are now 16bits as it should be, and not 8bits as a hack. - Added support for ICALL. - BIG ONE: Added support for data memory operatons, this includes: ld, ldd, st and std. This adds support for the reg+imm addressing mode when imm<64. - Print for ld, ldd, st and std when emmiting asm code the X, Y, Z names. I think this is it for the moment, probably i've left something out, but those are the basic points. I'm currently working in adding support for lds and sts, so we can load/store global symbols. And after that is implemented we'll be able to implement stack frames, which is an important milestone. I'll commit the new code in a few days, i want to get something done before. Let me know your thoughts. For me the most important part is to remark that we're moving further. PS: John do you get clang rebuilt each time you recompile LLVM, if that's the case do you know a way to stop this because linking it takes like 40secs here. Im using ccache as mentioned in some doc file. |
From: Weddington, E. <Eri...@at...> - 2011-04-01 17:54:43
|
> -----Original Message----- > From: Patrick Rosendahl [mailto:Pat...@gm...] > Sent: Friday, April 01, 2011 11:36 AM > To: avr...@li... > Subject: Re: [avr-llvm-devel] Building on windows / mingw > > There was some work on the register-allocation, so that 16bit moves can be > generated ( = adjacent pairs of 8bit registers). > What is the status on that? Can I help somewhere? > > Once someone decides how to deal with 16bit 'registers' in llvm, I think > implementing the instruction set is straight forward. Yeah, I'm hoping that we can get going on this soon. > Building: the patch-files are a little outdated, but you can fix the > failed lines easily by hand. > Thanks for the note! :-) Eric |
From: Weddington, E. <Eri...@at...> - 2011-04-01 17:53:53
|
> -----Original Message----- > From: John Myers [mailto:ato...@gm...] > Sent: Friday, April 01, 2011 9:46 AM > To: Weddington, Eric > Cc: avr...@li... > Subject: Re: [avr-llvm-devel] Building on windows / mingw > > > There is information in docs/gettingstarted.html and /trunk/README. > I've only built avr-llvm with Visual Studio on windows. But I believe you > need to use cmake > > for mingw also. Changing the '-G' option for cmake should be all that is > needed. Thanks John! I'll give it a shot. Eric |
From: Patrick R. <Pat...@gm...> - 2011-04-01 17:36:17
|
There was some work on the register-allocation, so that 16bit moves can be generated ( = adjacent pairs of 8bit registers). What is the status on that? Can I help somewhere? Once someone decides how to deal with 16bit 'registers' in llvm, I think implementing the instruction set is straight forward. Building: the patch-files are a little outdated, but you can fix the failed lines easily by hand. /Patrick On 31.03.2011, at 19:02, Weddington, Eric wrote: > Hi All, > > It's been a while since we've had some discussion about this project. I've been meaning to get around to building avr-llvm on windows / mingw. But first, I'd like to see the general directions on how to build avr-llvm. I know some things have changed since I first looked at those directions. Could someone point me to a document that provides the current build directions? > > Thanks, > Eric Weddington |
From: John M. <ato...@gm...> - 2011-04-01 15:45:49
|
On Thu, Mar 31, 2011 at 10:02 AM, Weddington, Eric < Eri...@at...> wrote: > Hi All, > > It's been a while since we've had some discussion about this project. I've > been meaning to get around to building avr-llvm on windows / mingw. But > first, I'd like to see the general directions on how to build avr-llvm. I > know some things have changed since I first looked at those directions. > Could someone point me to a document that provides the current build > directions? > > Thanks, > Eric Weddington > There is information in *docs/gettingstarted.html* and */trunk/README*. I've only built avr-llvm with Visual Studio on windows. But I believe you need to use cmake for mingw also. Changing the '-G' option for cmake should be all that is needed. --John |
From: Weddington, E. <Eri...@at...> - 2011-03-31 17:02:17
|
Hi All, It's been a while since we've had some discussion about this project. I've been meaning to get around to building avr-llvm on windows / mingw. But first, I'd like to see the general directions on how to build avr-llvm. I know some things have changed since I first looked at those directions. Could someone point me to a document that provides the current build directions? Thanks, Eric Weddington |
From: Borja F. <bor...@gm...> - 2010-12-12 14:02:01
|
I'm currently working with the PBQP allocator to add the pairing constraints. It can manage ordered pairs, for it, we need to tell if a virtual register is mapped to the lo or the hi part of the data to produce the correct code. John, now that atleast the pairing stuff is a bit clearer for the moment, we have to look at inserting 16 bit instructions like movw and adiw/sbiw. You can look at the pass i wrote to replace moves with movws, ideally i would like LLVM to do it automatically but i dont know if this is possible, so i guess this is what we need to investigate before proceeding into other things. |
From: John M. <ato...@gm...> - 2010-12-06 06:57:33
|
On Sun, Dec 5, 2010 at 10:40 AM, Borja Ferrer <bor...@gm...> wrote: > I'm currently discussing this issue in the llvmdev mailing list because it > seems there's no easy way to work with register pairs. You can check it in > the thread with title "Register Pairing". Basically this is the code im > testing, it shows how some regs arent paired correctly missing movw > insertion opportunities: > <snip> > ; here we have the case i was explaining, pairs dont match because they're > the other way round, function result is in r25:r24 > ; but it's storing the hi part in r20 instead of r21, so we cant insert a > movw > mov r20, r25 > mov r21, r24 <--- should be mov r21, r25; mov r20, r24 to be able to > insert a movw > <snip> > John if you have any suggestions they're welcome. I've also asked how to > combine two 8 bit instructions into a 16 bit one, mainly for movw and > adiw/sbiw. I wrote a function pass that searches 2 moves in a row and > combines them into a movw, but if other instructions get in between the > moves like it happens in the previous example (note those ands and xors) > then they get missed. GCC has an easy way of handling the register pairing > issue, Lang in the mailing list suggested using his register allocator which > is able to work with constraints like the ones we have, look in the src for > PBQP. > It's starting to sound like, from reading the other thread, that we will need to modify the LLVM code generator and/or tablegen to get the registers to be assigned in the correct order. So the PBQP solver can create pairs but I'm wondering if it will it also be able to assign them in the correct order? The PBQP sounds really interesting. I've tried reading up on the concept a few times before but still haven't looked at the source code yet. |
From: Borja F. <bor...@gm...> - 2010-12-05 18:40:11
|
I'm currently discussing this issue in the llvmdev mailing list because it seems there's no easy way to work with register pairs. You can check it in the thread with title "Register Pairing". Basically this is the code im testing, it shows how some regs arent paired correctly missing movw insertion opportunities: typedef short t; extern t mcos(t a); extern t mdiv(t a, t b); t foo(t a, t b) { short p1 = mcos(b); short p2 = mcos(a); return mdiv(p1&p2, p1^p2); } This C code produces (for purists, ignore the fact that it's using scratch regs between calls, this is unimplemented): ; a<- r25:r24 b<--r23:r22 mov r18, r24 mov r19, r25 <-- can be combined into a movw r19:r18, r25:r24 mov r25, r23 mov r24, r22 <-- can be combined into a movw r25:r24, r23:r22 call mcos ; here we have the case i was explaining, pairs dont match because they're the other way round, function result is in r25:r24 ; but it's storing the hi part in r20 instead of r21, so we cant insert a movw mov r20, r25 mov r21, r24 <--- should be mov r21, r25; mov r20, r24 to be able to insert a movw mov r25, r19 mov r24, r18 <-- can be combined into a movw r25:r24, r19:r18 call mcos ; same problem as above, again it's moving the hi part in r25 into r18 instead of r19 so we've lost another movw here mov r18, r25 <-- should be mov r19, r25 and r18, r20 mov r19, r24 <-- should be mov r18, r24 and r19, r21 mov r23, r25 <-- this * eor r23, r20 mov r22, r24 <-- * and this could be combined into movw r23:r22, r25:r24 eor r22, r21 mov r25, r18 mov r24, r19 <-- because the result returned by the second call to mcos is stored in r18:r19 (other way round) ; we've lost another movw call mdiv ret John if you have any suggestions they're welcome. I've also asked how to combine two 8 bit instructions into a 16 bit one, mainly for movw and adiw/sbiw. I wrote a function pass that searches 2 moves in a row and combines them into a movw, but if other instructions get in between the moves like it happens in the previous example (note those ands and xors) then they get missed. GCC has an easy way of handling the register pairing issue, Lang in the mailing list suggested using his register allocator which is able to work with constraints like the ones we have, look in the src for PBQP. |
From: Weddington, E. <Eri...@at...> - 2010-11-29 18:07:14
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Friday, November 26, 2010 4:28 AM > To: avr...@li... > Subject: Re: [avr-llvm-devel] Important stuff > > During the past few days i've been investigating how to do this, i'm > playing with the register file description and custom lowering. What i > thought is to always use register pairs, split them to perform the 8 bit > operation and join them again for the next operation, of course this is > for data wider than 8bits. > Right now i'm getting promising results, but still needs improvement, llvm > is using a new register when splitting the pair instead of using the same > subreg. I'll continue investigating, and post any results, we really need > to get this clear before advancing into more complex operations like > memory stuff and branching. Thanks, Borja, for looking into this. Agreed that this is an important step to get right before doing more complex operations. Your help in this area is very much appreciated. :-) Eric Weddington |
From: Borja F. <bor...@gm...> - 2010-11-26 11:35:52
|
During the past few days i've been investigating how to do this, i'm playing with the register file description and custom lowering. What i thought is to always use register pairs, split them to perform the 8 bit operation and join them again for the next operation, of course this is for data wider than 8bits. Right now i'm getting promising results, but still needs improvement, llvm is using a new register when splitting the pair instead of using the same subreg. I'll continue investigating, and post any results, we really need to get this clear before advancing into more complex operations like memory stuff and branching. 2010/11/19 Borja Ferrer <bor...@gm...> > We need to figure out some important things that need to be introduced in > the compiler before we advance with bigger things. The things i'm talking > about are: > > 1) aligning data wider than 1 byte in even registers to favour movws and > argument passing into functions. > int16 a = b; // a = r21:r20, b = r13:r12 > movw r20, r12 <--- good reg allocation > > int16 a = b; // a = r20:r21, b = r12:r13 > mov r21, r13 > mov r20, r12 <--- bad reg allocation > > 2) THE BIG ONE: working with register pairs. there are some instructions > like sbiw/adiw, movw, ld/st that only work with register pairs. we need to > figure out how to introduce them. > For example, I wrote a pass that converts 2 moves in a row into a movw. > This is very basic, but i find it bad, because if the compiler places an > instruction between both moves this pass wont be able to replace it with the > movw. Also i find it very hacky, because the compiler doesnt know that there > is really a move instruction that work with 16bit data so it doesnt have a > global view of the costs and probably worsening reg allocation. > > If we worked with pseudo regs of 16 bits this should be straight forward, > but we would face the problem i mentioned some time ago, all data operations > would need custom lowering, because LLVM isnt able to split a wider reg into > subregs (say R1312 into R13:R12). An initial guess would be manually > splitting the reg into its subregs, perform the operation and finally > recombining the subregs again into the bigger one for next instruction, but > im not sure yet if this is a good solution. > > We really need to think about it because it's a very important design > decision. This was my first email into llvm's dev mailing list, but i really > didnt got any real solution. > If you can think of any other points related to this, add them. > > |
From: Borja F. <bor...@gm...> - 2010-11-19 14:08:27
|
We need to figure out some important things that need to be introduced in the compiler before we advance with bigger things. The things i'm talking about are: 1) aligning data wider than 1 byte in even registers to favour movws and argument passing into functions. int16 a = b; // a = r21:r20, b = r13:r12 movw r20, r12 <--- good reg allocation int16 a = b; // a = r20:r21, b = r12:r13 mov r21, r13 mov r20, r12 <--- bad reg allocation 2) THE BIG ONE: working with register pairs. there are some instructions like sbiw/adiw, movw, ld/st that only work with register pairs. we need to figure out how to introduce them. For example, I wrote a pass that converts 2 moves in a row into a movw. This is very basic, but i find it bad, because if the compiler places an instruction between both moves this pass wont be able to replace it with the movw. Also i find it very hacky, because the compiler doesnt know that there is really a move instruction that work with 16bit data so it doesnt have a global view of the costs and probably worsening reg allocation. If we worked with pseudo regs of 16 bits this should be straight forward, but we would face the problem i mentioned some time ago, all data operations would need custom lowering, because LLVM isnt able to split a wider reg into subregs (say R1312 into R13:R12). An initial guess would be manually splitting the reg into its subregs, perform the operation and finally recombining the subregs again into the bigger one for next instruction, but im not sure yet if this is a good solution. We really need to think about it because it's a very important design decision. This was my first email into llvm's dev mailing list, but i really didnt got any real solution. If you can think of any other points related to this, add them. |
From: Weddington, E. <Eri...@at...> - 2010-11-18 13:50:18
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Thursday, November 18, 2010 3:23 AM > To: avr...@li... > Subject: Re: [avr-llvm-devel] About rev 108 > > I agree that doing it incrementally simplifies the work instead of doing > it all once. I'll switch my current setup and use the llvm repository, > agreed? > Sounds good to me. Thanks again for all your help! :-) |
From: Borja F. <bor...@gm...> - 2010-11-18 10:23:28
|
I agree that doing it incrementally simplifies the work instead of doing it all once. I'll switch my current setup and use the llvm repository, agreed? 2010/11/18 Weddington, Eric <Eri...@at...> > > I kinda thought that doing it incrementally would keep overall hassles to a > minimum, plus it keeps us aware of what's happening on the trunk, rather > than keep working on old stuff. I think that was the rationale, though > admittedly I think that none of us has really strong opinions about it. > > Eric Weddington > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Wednesday, November 17, 2010 4:28 PM > > To: avr...@li... > > Subject: Re: [avr-llvm-devel] About rev 108 > > > > Well, i dont really care either, my current local setup is to only > support > > v2.8 and not trunk, this was my though on how it was going to be done. I > > noticed these changes in llvm's rep but didnt apply them because my idea > > was to merge them once we switched to 2.9. > > So if we have to work with trunk as the codebase instead of 2.8 now is > the > > moment to decide. > > > > > > 2010/11/17 John Myers <ato...@gm...> > > > > > > > > > > On Wed, Nov 17, 2010 at 3:58 AM, Borja Ferrer > > <bor...@gm...> wrote: > > > > > > Hello John i'm not at home now to check this but i've > noticed > > your last commit introduces a change that im unsure now if it's > compatible > > with our current code base which is v2.8. > > > > > -------------------------------------------------------------- > > ---------------- > > > > > > Yeah, the last few commits have been to synchronize with the LLVM > > trunk. I guess this is one if the development decisions we should have > > discussed before continuing. The way we were doing it before was to try > to > > keep the avr-llvm trunk up to date with the LLVM trunk. > > > > There are pros and cons for both methods (incremental vs. single > > shot). The other devs wanted to incrementally keep up with the LLVM > trunk, > > but personally I don't have a strong opinion either way. > > > > |
From: Weddington, E. <Eri...@at...> - 2010-11-18 02:03:13
|
I kinda thought that doing it incrementally would keep overall hassles to a minimum, plus it keeps us aware of what's happening on the trunk, rather than keep working on old stuff. I think that was the rationale, though admittedly I think that none of us has really strong opinions about it. Eric Weddington > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Wednesday, November 17, 2010 4:28 PM > To: avr...@li... > Subject: Re: [avr-llvm-devel] About rev 108 > > Well, i dont really care either, my current local setup is to only support > v2.8 and not trunk, this was my though on how it was going to be done. I > noticed these changes in llvm's rep but didnt apply them because my idea > was to merge them once we switched to 2.9. > So if we have to work with trunk as the codebase instead of 2.8 now is the > moment to decide. > > > 2010/11/17 John Myers <ato...@gm...> > > > > > On Wed, Nov 17, 2010 at 3:58 AM, Borja Ferrer > <bor...@gm...> wrote: > > > Hello John i'm not at home now to check this but i've noticed > your last commit introduces a change that im unsure now if it's compatible > with our current code base which is v2.8. > > -------------------------------------------------------------- > ---------------- > > > Yeah, the last few commits have been to synchronize with the LLVM > trunk. I guess this is one if the development decisions we should have > discussed before continuing. The way we were doing it before was to try to > keep the avr-llvm trunk up to date with the LLVM trunk. > > There are pros and cons for both methods (incremental vs. single > shot). The other devs wanted to incrementally keep up with the LLVM trunk, > but personally I don't have a strong opinion either way. > |
From: Borja F. <bor...@gm...> - 2010-11-17 23:27:53
|
Well, i dont really care either, my current local setup is to only support v2.8 and not trunk, this was my though on how it was going to be done. I noticed these changes in llvm's rep but didnt apply them because my idea was to merge them once we switched to 2.9. So if we have to work with trunk as the codebase instead of 2.8 now is the moment to decide. 2010/11/17 John Myers <ato...@gm...> > > > On Wed, Nov 17, 2010 at 3:58 AM, Borja Ferrer <bor...@gm...>wrote: > >> Hello John i'm not at home now to check this but i've noticed your last >> commit introduces a change that im unsure now if it's compatible with our >> current code base which is v2.8. >> >> ------------------------------------------------------------------------------ >> > Yeah, the last few commits have been to synchronize with the LLVM trunk. I > guess this is one if the development decisions we should have discussed > before continuing. The way we were doing it before was to try to keep the > avr-llvm trunk up to date with the LLVM trunk. > > There are pros and cons for both methods (incremental vs. single shot). The > other devs wanted to incrementally keep up with the LLVM trunk, but > personally I don't have a strong opinion either way. > |
From: John M. <ato...@gm...> - 2010-11-17 22:40:55
|
On Wed, Nov 17, 2010 at 3:58 AM, Borja Ferrer <bor...@gm...> wrote: > Hello John i'm not at home now to check this but i've noticed your last > commit introduces a change that im unsure now if it's compatible with our > current code base which is v2.8. > > ------------------------------------------------------------------------------ > Yeah, the last few commits have been to synchronize with the LLVM trunk. I guess this is one if the development decisions we should have discussed before continuing. The way we were doing it before was to try to keep the avr-llvm trunk up to date with the LLVM trunk. There are pros and cons for both methods (incremental vs. single shot). The other devs wanted to incrementally keep up with the LLVM trunk, but personally I don't have a strong opinion either way. |
From: Borja F. <bor...@gm...> - 2010-11-17 12:06:28
|
I've been very busy these days so i haven't got time to discuss this with my friend, i hope to do it in the next few days. Also mention that during my nearly inexistent spare time i've been reading the codegeneration source code line by line to grasp all the low level details to get a better general view in how to continue developing the backend. I had some doubts about DAGs that i've resolved by reading the code. I would like to finish reading it (70% done) before writing more code in order to do it as better as possible. 2010/11/10 Borja Ferrer <bor...@gm...> > >>Obviously all the real decisions, especially on what's worth spending > time on, need to be made by the people actually spending their > >> time doing the work. > Yes Kevin, but the more opinions and arguments we get the better we'll be > able to decide, because this is as a C standard issue that is always hard to > decide. > > >> In all reality, wouldn't avr-llvm have to work with avr-libc as it's > standard C library? > Yes, i've never thought of using a different C library or remaking a new > one, my opinion is that we should stick to it. > > > 2010/11/10 Weddington, Eric <Eri...@at...> > > >> >> > -----Original Message----- >> > From: John Myers [mailto:ato...@gm...] >> > Sent: Tuesday, November 09, 2010 4:47 PM >> > To: Weddington, Eric >> > Cc: Borja Ferrer; avr...@li... >> > Subject: Re: [avr-llvm-devel] Load / Store >> > >> > >> > >> >> > I don't believe it does. What part of the standard do you >> > think it violates? The C language standard doesn't really >> > deal with multiple address spaces so it can't be an explicit >> > violation of the standard. >> >> There is a draft change to the standard that deals with multiple address >> spaces. The work that has been done in GCC for multiple address spaces >> conforms to this draft. >> >> > I even see a superscript text note >> > in the draft of the standard that says: "implementations may >> > place a const object that is not volatile in a read-only >> > region of storage". >> >> Hmm. Ok, so I'm wrong. :-) >> >> Most implementations I've seen have a semantic difference between >> something that is just *read only* and actually placing it in a different >> address space. >> >> If we don't equate the two it might make implementation easier though. >> > > |