Menu
▾
▴
avr-llvm-devel — Developers mailing list.
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: John M. <ato...@gm...> - 2010-11-02 03:33:54
|
> Another thing, i dont know how feasible is doing this, but should we make > program and data space addrs transparent to the user? > Yes I believe that would be a useful feature. I think we should try as much as possible without, of course, violating any language standards. It would allow users to write more portable/generic code. We probable should have a command line option to enable/disable this so users have more control. LLVM has an address space qualifier mechanism already so I don't think it will take too much work. I think most of the work of making it transparent will need to be done in the front ends and optimizer passes. Either way (like a lot of commercial embedded compilers) we'll need to extend the type qualifiers to include things like *flash*, *eeprom*, *near* / *far *pointers... |
|
From: Borja F. <bor...@gm...> - 2010-11-01 19:15:00
|
Hello, during the last few days i've been playing a bit with memory operations, in particular with load and stores but with big hacks. AVR's memory operations arent very standard because they only work with three reg pairs, and the X ptr version doesnt allow adding an offset, so we end up having sort of 2 different addressing capabilities. I started doing a big hack, saying that a ptr is 8 bits wide instead of 16, this allows matching the st and ld instructions without any further complexities. Now i need to figure out how to customize st/ld so it takes in a register pair to form a 16bit ptr. This brings some doubts: - If ptrs were 8 bits we could have a reg class with r26, r28 and r30 for st/ld and the compiler would be able to choose between this class what reg to use. However we have to stick with reg pairs so we have to think how to overcome this, if we dont use reg classes will we have to decide which pair has to be used manually in each operation??. Also notice that we should try to avoid using X to access struct members or whatever because it doesnt support doing "X+<offs>" so we have to see how to handle different addressing modes, favouring Y or Z in such cases etc. Another thing, i dont know how feasible is doing this, but should we make program and data space addrs transparent to the user? any design consideration replies are welcome |
|
From: John M. <ato...@gm...> - 2010-10-18 02:41:11
|
On Sat, Oct 16, 2010 at 2:14 PM, Borja Ferrer <bor...@gm...> wrote: > Excellent, i'm about to commit the changes into trunk. Another thing to > mention is that after merging your changes in asmprinter i noticed that > symbol names dont get printed in the asm file anymore. For example try > making a function call and you'll notice you get > call > instead of > call foo > Oops, that was a copy/paste error. I deleted a line by accident in AVRInstPrinter.cpp. |
|
From: Borja F. <bor...@gm...> - 2010-10-16 21:42:15
|
Ok code commited, i guess having this done now, we should move on in discussing and planning some development. 2010/10/16 Borja Ferrer <bor...@gm...> > Excellent, i'm about to commit the changes into trunk. Another thing to > mention is that after merging your changes in asmprinter i noticed that > symbol names dont get printed in the asm file anymore. For example try > making a function call and you'll notice you get > call > instead of > call foo > > 2010/10/16 John Myers <ato...@gm...> > > >> >> On Sat, Oct 16, 2010 at 5:05 AM, Borja Ferrer <bor...@gm...>wrote: >> >>> Hello John, i've just merged into the branch more useful code from trunk, >>> let me know if you're ok with that so that we can merge it into trunk. Does >>> your changes to Asmprinter compile and build so i can merge them into the >>> branch, or do they need more work? >>> >>> >> Hi Borja, >> I'm OK with merging that into trunk. >> I've updated the files in */trunk/AVR/AsmPrinter* so now they >> compile/build against version 2.8. >> >> --John >> >> > |
|
From: Borja F. <bor...@gm...> - 2010-10-16 21:14:39
|
Excellent, i'm about to commit the changes into trunk. Another thing to mention is that after merging your changes in asmprinter i noticed that symbol names dont get printed in the asm file anymore. For example try making a function call and you'll notice you get call instead of call foo 2010/10/16 John Myers <ato...@gm...> > > > On Sat, Oct 16, 2010 at 5:05 AM, Borja Ferrer <bor...@gm...>wrote: > >> Hello John, i've just merged into the branch more useful code from trunk, >> let me know if you're ok with that so that we can merge it into trunk. Does >> your changes to Asmprinter compile and build so i can merge them into the >> branch, or do they need more work? >> >> > Hi Borja, > I'm OK with merging that into trunk. > I've updated the files in */trunk/AVR/AsmPrinter* so now they > compile/build against version 2.8. > > --John > > |
|
From: John M. <ato...@gm...> - 2010-10-16 19:41:24
|
On Sat, Oct 16, 2010 at 5:05 AM, Borja Ferrer <bor...@gm...> wrote: > Hello John, i've just merged into the branch more useful code from trunk, > let me know if you're ok with that so that we can merge it into trunk. Does > your changes to Asmprinter compile and build so i can merge them into the > branch, or do they need more work? > > Hi Borja, I'm OK with merging that into trunk. I've updated the files in */trunk/AVR/AsmPrinter* so now they compile/build against version 2.8. --John |
|
From: Borja F. <bor...@gm...> - 2010-10-16 12:05:35
|
Hello John, i've just merged into the branch more useful code from trunk, let me know if you're ok with that so that we can merge it into trunk. Does your changes to Asmprinter compile and build so i can merge them into the branch, or do they need more work? |
|
From: Borja F. <bor...@gm...> - 2010-10-15 19:48:07
|
About all the Asmprinter stuff, trunk's wont compile because many things have changed in the Asmprinter stuff during this release, so i didnt bothered touching it. In fact, my asmprinter code is a direct copy of another target without any customization (there's a big note at the top of the cpp file about this). Basically, i decided to leave this part for later on until codegen was more developed. You may want to take a look into this. Gah i have to leave, i'll continue commenting later. 2010/10/15 John Myers <ato...@gm...> > > > On Tue, Oct 12, 2010 at 11:25 AM, Borja Ferrer <bor...@gm...>wrote: > >> ... >> >> >> So now that the code is there (going to wait 2 more days until we merge it >> into trunk incase you find anything that has to be changed), i guess we >> should proceed in planning how to continue the work. >> >> > This is how I see the merge happening so far after comparing the branches. > > /AVR/TargetInfo/AVRTargetInfo.cpp := ~same > > /AVR/AsmPrinter/AVRAsmPrinter.cpp := trunk has more AVR specific stuff > > /AVR/AVR.td := ~same > /AVR/AVR.h := ~same > > /faluco/AVR/AVR16bitInstPass.cpp := mv to trunk > > /AVR/AVRCallingConv.td := use faluco > /AVR/AVRInstrFormats.td := use faluco > > /AVR/AVRInstrInfo.cpp|h := use faluco, add any useful stuff > from trunk > > /AVR/AVRInstrInfo.td := use faluco, merge predicates from > trunk > > > /AVR/AVRISelDAGToDAG.cpp := use faluco > /AVR/AVRISelLowering.cpp|h := use faluco > > /AVR/AVRMCAsmInfo.cpp|h := merge > /AVR/AVRRegisterInfo.cpp|h := merge > > /AVR/AVRRegisterInfo.td := use faluco > > /AVR/AVRSelectionDAGInfo.cpp|h := mv to trunk > > /AVR/AVRSubtarget.cpp|h := use trunk, merge for consistency > > /AVR/AVRTargetMachine.cpp|h := use faluco > |
|
From: John M. <ato...@gm...> - 2010-10-15 18:53:47
|
On Tue, Oct 12, 2010 at 11:25 AM, Borja Ferrer <bor...@gm...>wrote: > ... > > So now that the code is there (going to wait 2 more days until we merge it > into trunk incase you find anything that has to be changed), i guess we > should proceed in planning how to continue the work. > > This is how I see the merge happening so far after comparing the branches. /AVR/TargetInfo/AVRTargetInfo.cpp := ~same /AVR/AsmPrinter/AVRAsmPrinter.cpp := trunk has more AVR specific stuff /AVR/AVR.td := ~same /AVR/AVR.h := ~same /faluco/AVR/AVR16bitInstPass.cpp := mv to trunk /AVR/AVRCallingConv.td := use faluco /AVR/AVRInstrFormats.td := use faluco /AVR/AVRInstrInfo.cpp|h := use faluco, add any useful stuff from trunk /AVR/AVRInstrInfo.td := use faluco, merge predicates from trunk /AVR/AVRISelDAGToDAG.cpp := use faluco /AVR/AVRISelLowering.cpp|h := use faluco /AVR/AVRMCAsmInfo.cpp|h := merge /AVR/AVRRegisterInfo.cpp|h := merge /AVR/AVRRegisterInfo.td := use faluco /AVR/AVRSelectionDAGInfo.cpp|h := mv to trunk /AVR/AVRSubtarget.cpp|h := use trunk, merge for consistency /AVR/AVRTargetMachine.cpp|h := use faluco |
|
From: Borja F. <bor...@gm...> - 2010-10-12 18:25:57
|
Thanks Josef, that was exactly what i was looking for, btw, i dont know why i didnt receive your email, had to read it through SF. John basically I wanted to know how you managed here to build the backend having the code repository outside the LLVM source tree, thanks for the info. For now im working with llvm-gcc instead of clang in linux, didnt want to mix things for now, so i went with the easiest thing. This means that data type sizes arent going to match the AVR ABI for me in a while, but i think this shouldnt be a problem since we're not writing AVR code. So now that the code is there (going to wait 2 more days until we merge it into trunk incase you find anything that has to be changed), i guess we should proceed in planning how to continue the work. |
|
From: John M. <ato...@gm...> - 2010-10-12 17:56:49
|
On Tue, Oct 12, 2010 at 4:20 AM, Borja Ferrer <bor...@gm...> wrote: > Nice, what do you think about the generated code? > > It looks good. I haven't tried out anything fancy yet, just some of the files in the* /trunk/testcases*. Let me ask you an unrelated question, how have you set up the backend code > having the LLVM source code out of SVN? > > I'm not sure what you mean? Are you asking how I setup the src code for building the compiler? The source code I build is still under SVN control I just checkout */llvm/tags/release_28* and then checkout the AVR branch into*lib/Target/ *. On Windows I actually checkout the whole avr-llvm and then make a directory junction link (mklink /J) into *lib/Target/*. > 2010/10/12 John Myers <ato...@gm...> > > >> >> On Sun, Oct 10, 2010 at 5:01 AM, Borja Ferrer <bor...@gm...>wrote: >> >>> Hello, i've just finished updating my code to the new LLVM version >>> released some days ago, after this I've merged it to your codebase making >>> the appropriate changes. As a start i decided to commit it to a branch >>> before touching trunk so you can take a look and test it. >>> >>> To build it, just download the LLVM source code, apply the patches to >>> Triple.h/cpp and build it. >>> >>> Let me know your thoughts. >>> >>> >> Hi Borja, >> >> I think it's OK to start merging your *branch* into the *trunk*. >> I've successfully built it on Linux and Windows and played around with it >> a little bit. >> >> >> >> --John >> > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > |
|
From: Josef E. <za...@za...> - 2010-10-12 13:37:58
|
Hello and a welcome from my side. On 10/12/2010 01:20 PM, Borja Ferrer wrote: > Nice, what do you think about the generated code? > > Let me ask you an unrelated question, how have you set up the backend > code having the LLVM source code out of SVN? There is some documentation (gettingstarted.html, devel.html) in the doc folder (llvm/trunk/docs/). I think thats what you are looking for. BR Josef > > 2010/10/12 John Myers <ato...@gm... > <mailto:ato...@gm...>> > > > > On Sun, Oct 10, 2010 at 5:01 AM, Borja Ferrer <bor...@gm... > <mailto:bor...@gm...>> wrote: > > Hello, i've just finished updating my code to the new LLVM > version released some days ago, after this I've merged it to > your codebase making the appropriate changes. As a start i > decided to commit it to a branch before touching trunk so you > can take a look and test it. > > To build it, just download the LLVM source code, apply the > patches to Triple.h/cpp and build it. > > Let me know your thoughts. > > > Hi Borja, > > I think it's OK to start merging your /branch/ into the /trunk/. > I've successfully built it on Linux and Windows and played around > with it a little bit. > > > > --John > > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > > > > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel |
|
From: Borja F. <bor...@gm...> - 2010-10-12 11:20:27
|
Nice, what do you think about the generated code? Let me ask you an unrelated question, how have you set up the backend code having the LLVM source code out of SVN? 2010/10/12 John Myers <ato...@gm...> > > > On Sun, Oct 10, 2010 at 5:01 AM, Borja Ferrer <bor...@gm...>wrote: > >> Hello, i've just finished updating my code to the new LLVM version >> released some days ago, after this I've merged it to your codebase making >> the appropriate changes. As a start i decided to commit it to a branch >> before touching trunk so you can take a look and test it. >> >> To build it, just download the LLVM source code, apply the patches to >> Triple.h/cpp and build it. >> >> Let me know your thoughts. >> >> > Hi Borja, > > I think it's OK to start merging your *branch* into the *trunk*. > I've successfully built it on Linux and Windows and played around with it a > little bit. > > > > --John > |
|
From: John M. <ato...@gm...> - 2010-10-12 02:51:01
|
On Sun, Oct 10, 2010 at 5:01 AM, Borja Ferrer <bor...@gm...> wrote: > Hello, i've just finished updating my code to the new LLVM version released > some days ago, after this I've merged it to your codebase making the > appropriate changes. As a start i decided to commit it to a branch before > touching trunk so you can take a look and test it. > To build it, just download the LLVM source code, apply the patches to > Triple.h/cpp and build it. > > Let me know your thoughts. > > Hi Borja, I think it's OK to start merging your *branch* into the *trunk*. I've successfully built it on Linux and Windows and played around with it a little bit. --John |
|
From: Borja F. <bor...@gm...> - 2010-10-10 12:01:10
|
Hello, i've just finished updating my code to the new LLVM version released some days ago, after this I've merged it to your codebase making the appropiate changes. As a start i decided to commit it to a branch before touching trunk so you can take a look and test it. To build it, just download the LLVM source code, apply the patches to Triple.h/cpp and build it. Let me know your thoughts. |
|
From: Borja F. <bor...@gm...> - 2010-10-03 12:47:37
|
Yes, but im unsure if my 2.7 gcc-llvm binaries will work with this new version. 2010/10/3 John Myers <ato...@gm...> > You can also work off of */llvm/branches/release_28*. No major changes to > the function prototypes and class interfaces should happen at this point. > > On Sat, Oct 2, 2010 at 4:34 PM, Borja Ferrer <bor...@gm...>wrote: > >> LLVM's new version hasnt't been released yet, hope it doesnt get delayed >> too much. In the meantime i've been cleaning a bit my code to make it ready >> to be updated. >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> avr-llvm-devel mailing list >> avr...@li... >> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel >> >> > |
|
From: John M. <ato...@gm...> - 2010-10-03 03:29:02
|
You can also work off of */llvm/branches/release_28*. No major changes to the function prototypes and class interfaces should happen at this point. On Sat, Oct 2, 2010 at 4:34 PM, Borja Ferrer <bor...@gm...> wrote: > LLVM's new version hasnt't been released yet, hope it doesnt get delayed > too much. In the meantime i've been cleaning a bit my code to make it ready > to be updated. > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > |
|
From: Borja F. <bor...@gm...> - 2010-10-02 23:34:41
|
LLVM's new version hasnt't been released yet, hope it doesnt get delayed too much. In the meantime i've been cleaning a bit my code to make it ready to be updated. |
|
From: Weddington, E. <Eri...@at...> - 2010-09-28 23:36:28
|
Excellent! :-)
Let us know how the new LLVM version is looking, and what will have to be done to get avr-llvm to match...
Thanks,
Eric Weddington
> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Tuesday, September 28, 2010 2:56 PM
> To: avr...@li...
> Subject: [avr-llvm-devel] Fwd: New backend implementation
>
> I've just finished fixing the register calling convention. I
> had a huge TODO in my code to handle passing chars in even
> registers and returning a char in R24. I couldnt use the
> typical approach of using the Tablegen code to define the
> calling convention because wide arguments are splitted into
> i8 pieces making LLVM treat all args as chars so there was no
> easy way of knowing the real size of each arg. I had to write
> it down in C++ code to check the real argument size and
> allocate the regs using AVR's ABI spec.
>
>
> A piece of code to show it:
>
> typedef int t;
> t foo(t a, t b, char c, int d)
> {
> return a+b+d;
> }
>
> foo: # @foo
> .ent foo
> # BB#0: # %entry
> add r22, r18
> adc r23, r19
> adc r24, r20
> adc r25, r21
> add r22, r12
> adc r23, r13
> adc r24, r14
> adc r25, r15
> ret
>
> GCC generated this:
>
> 120: cf 92 push r12
> 122: df 92 push r13
> 124: ef 92 push r14
> 126: ff 92 push r15
> return (a + b +d);
> 128: 26 0f add r18, r22
> 12a: 37 1f adc r19, r23
> 12c: 48 1f adc r20, r24
> 12e: 59 1f adc r21, r25
> 130: 2c 0d add r18, r12
> 132: 3d 1d adc r19, r13
> 134: 4e 1d adc r20, r14
> 136: 5f 1d adc r21, r15
> 138: b9 01 movw r22, r18
> 13a: ca 01 movw r24, r20
> 13c: ff 90 pop r15
> 13e: ef 90 pop r14
> 140: df 90 pop r13
> 142: cf 90 pop r12
> 144: 08 95 ret
>
> Forget the fact that our code isnt saving regs into the
> stack, that's currently unimplemented, but notice those two
> movws are totally redundant, pretty funny.
> LLVM's site states that the new version will get released
> tomorrow, so i'll start porting my code once that is done.
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2010-09-28 20:56:26
|
I've just finished fixing the register calling convention. I had a huge TODO
in my code to handle passing chars in even registers and returning a char in
R24. I couldnt use the typical approach of using the Tablegen code to define
the calling convention because wide arguments are splitted into i8 pieces
making LLVM treat all args as chars so there was no easy way of knowing the
real size of each arg. I had to write it down in C++ code to check the real
argument size and allocate the regs using AVR's ABI spec.
A piece of code to show it:
typedef int t;
t foo(t a, t b, char c, int d)
{
return a+b+d;
}
foo: # @foo
.ent foo
# BB#0: # %entry
add r22, r18
adc r23, r19
adc r24, r20
adc r25, r21
add r22, r12
adc r23, r13
adc r24, r14
adc r25, r15
ret
GCC generated this:
120: cf 92 push r12
122: df 92 push r13
124: ef 92 push r14
126: ff 92 push r15
return (a + b +d);
128: 26 0f add r18, r22
12a: 37 1f adc r19, r23
12c: 48 1f adc r20, r24
12e: 59 1f adc r21, r25
130: 2c 0d add r18, r12
132: 3d 1d adc r19, r13
134: 4e 1d adc r20, r14
136: 5f 1d adc r21, r15
138: b9 01 movw r22, r18
13a: ca 01 movw r24, r20
13c: ff 90 pop r15
13e: ef 90 pop r14
140: df 90 pop r13
142: cf 90 pop r12
144: 08 95 ret
Forget the fact that our code isnt saving regs into the stack, that's
currently unimplemented, but notice those two movws are totally redundant,
pretty funny.
LLVM's site states that the new version will get released tomorrow, so i'll
start porting my code once that is done.
|
|
From: Weddington, E. <Eri...@at...> - 2010-09-27 15:59:03
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Sunday, September 26, 2010 5:41 PM > To: avr...@li... > Subject: Re: [avr-llvm-devel] New backend implementation > > I think we should stay away of customizing as much as > possible and let LLVM do the work, Totally agreed. :-) |
|
From: Borja F. <bor...@gm...> - 2010-09-26 23:41:16
|
Eric, we could start with 8 bit regs for now and if we find that we can make register pairs work we can then switch to use them. John, sadly expansion wont work here because LLVM is not able to split the pairs into single regs thus it cant find any 16 bit instructions. If we work with 8 bit regs it will expand the code correctly, in fact, i didnt even add the setOperandAction line, LLVM will do it automatically. Custom lowering is a possible solution but im unsure now if it's the best. First i have to say that i tried custom lowering the add instruction without success because it involved splitting regs (i managed to do this) but i failed at rebuilding the pairs because it involved using a 16bit OR instruction which needed custom lowering and this also needed a 16 bit OR so the story loops forever. I tried this the second day of development so by that time i didnt have a very clear view yet of the compiler, dont know if by now i would be able to do it. You may want to read the discussion i had in the LLVM dev list in here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-August/034203.html search for the same subject in september aswell to read the whole thread. I think we should stay away of customizing as much as possible and let LLVM do the work, when i tried custom lowering i did it with DAG nodes and not by inserting manually instructions with BuildMI() which is horrible in my opinion because it takes away a lot of information to the codegen passes and from what i've seen this is what GCC does, i took at look at GCC's .md file and inside it you can find every single operation with custom assembly. A test i did was a multiplication by a constant (something like short a = b * 53, unsure now if this was the exact code), GCC would emit a mul and all the add chain instructions being the high part of the constant 0 so all this could have been saved, however LLVM noticed this and saved these mentioned instructions, and i think this is caused because GCC's operations are all manually written in the .md, i dont know too much about GCC so i may be wrong though but the test im explaining is for real. We could try customizing but only using DAG nodes, but notice this would involve doing it for every single operation and size. Currently the trouble i can think of using 8 bit regs is that we have to tell LLVM to alloc 16 bit or wider data in odd:even pairs and how to bring in the movws, but we can discuss this later on. |
|
From: John M. <ato...@gm...> - 2010-09-26 22:39:08
|
Hi Borja, We haven't got to the point of testing values greater then 8 bits. I thought these things were suppose to be taken care if in AVRISelLowering.cpp? I haven't really looked into this much but doesn't the legalize action of * Expand* take care of this? If not what about the custom lowering? setOperationAction(ISD::ADD, MVT::i16, Expand); On Sun, Sep 26, 2010 at 10:00 AM, Borja Ferrer <bor...@gm...>wrote: > I've been taking a look at the code and noticed an important design issue > you took. It's about how registers are defined in the RegisterInfo.td file. > Defining register pairs is a good idea and in fact i did the same because it > simplifies many things, BUT, that brought some problems after i did more > testing. I noticed it when i tried to do a 16bit addition. LLVM will store > the operands in two different pairs but then it wont know how to perform the > addition because all add/sub instructions (ignoring ADIW) work with 8 bit > regs. What i supposed is that LLVM would be able to split the register pair > into individual regs perform the addition and then fuse them again into the > pair, but i was too optimisitc, it doesnt handle things that way. This issue > was the subject of my first email to the LLVM dev list. > So at the end i had to work only with 8 bit regs, that way LLVM is smart to > expand arithmetic operators of any size into a chain of add/addc > instructions in the case of the "+" operator. If you did the same assumption > i did then probably you would have faced this once you tested this case, but > if you did it for another purpose then we can discuss this further to see > how solve this problem. > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > |
|
From: Weddington, E. <Eri...@at...> - 2010-09-26 17:16:04
|
Hi Borja, I think that, at this point, if you feel that a certain design decision needs to be changed because it will get us farther in generating code, then you should feel free to make those changes as you deem necessary. If there are any issues, I'm sure that we'll discuss them here on the list. Eric Weddington > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Sunday, September 26, 2010 11:01 AM > To: avr...@li... > Subject: Re: [avr-llvm-devel] New backend implementation > > I've been taking a look at the code and noticed an important > design issue you took. It's about how registers are defined > in the RegisterInfo.td file. Defining register pairs is a > good idea and in fact i did the same because it simplifies > many things, BUT, that brought some problems after i did more > testing. I noticed it when i tried to do a 16bit addition. > LLVM will store the operands in two different pairs but then > it wont know how to perform the addition because all add/sub > instructions (ignoring ADIW) work with 8 bit regs. What i > supposed is that LLVM would be able to split the register > pair into individual regs perform the addition and then fuse > them again into the pair, but i was too optimisitc, it doesnt > handle things that way. This issue was the subject of my > first email to the LLVM dev list. > So at the end i had to work only with 8 bit regs, that way > LLVM is smart to expand arithmetic operators of any size into > a chain of add/addc instructions in the case of the "+" > operator. If you did the same assumption i did then probably > you would have faced this once you tested this case, but if > you did it for another purpose then we can discuss this > further to see how solve this problem. > > > |
|
From: Borja F. <bor...@gm...> - 2010-09-26 17:01:03
|
I've been taking a look at the code and noticed an important design issue you took. It's about how registers are defined in the RegisterInfo.td file. Defining register pairs is a good idea and in fact i did the same because it simplifies many things, BUT, that brought some problems after i did more testing. I noticed it when i tried to do a 16bit addition. LLVM will store the operands in two different pairs but then it wont know how to perform the addition because all add/sub instructions (ignoring ADIW) work with 8 bit regs. What i supposed is that LLVM would be able to split the register pair into individual regs perform the addition and then fuse them again into the pair, but i was too optimisitc, it doesnt handle things that way. This issue was the subject of my first email to the LLVM dev list. So at the end i had to work only with 8 bit regs, that way LLVM is smart to expand arithmetic operators of any size into a chain of add/addc instructions in the case of the "+" operator. If you did the same assumption i did then probably you would have faced this once you tested this case, but if you did it for another purpose then we can discuss this further to see how solve this problem. |
14 messages has been excluded from this view by a project administrator.
