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: Weddington, E. <Eri...@at...> - 2012-03-06 19:32:16
|
Well, we don't have to slavishly follow GCC either. What do you think? If you were a programmer, would you want the compiler to warn you, then not apply the attribute and continue compilation? Should the compiler assume that you did not want the attribute to be applied in the case of a non-void function or one with arguments? The compiler really doesn't know what the fix should be. I would think, that in this case, it really is equivalent to a syntax error. These attributes are only allowed on a non-void, non-argument function. Otherwise, the user needs to the fix the code to expressly say what needs to be done. This is outside the realm of the C standard, since we're dealing with function attributes and ISRs. Again, what do you think? Eric Weddington > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Tuesday, March 06, 2012 12:22 PM > To: Weddington, Eric > Cc: avr...@li... > Subject: Re: [avr-llvm-devel] Interrupt handling > > It issues a warning, so, it doesn't apply the attribute and it doesn't abort > compilation. I checked gcc and it warns aswell. However i can error out if > it's better, i leave that up to you. > > > 2012/3/6 Weddington, Eric <Eri...@at...> > > > > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > > Sent: Tuesday, March 06, 2012 11:57 AM > > To: Weddington, Eric > > Cc: avr...@li... > > Subject: Re: [avr-llvm-devel] Interrupt handling > > > > > I've added some checks to the frontend when setting the > signal/interrupt > > attribute that are the following: > > > > 1) warn when the attrib is used in things that aren't function > declarations. > > 2) warn when the function has arguments > > 3) warn when the function doesnt return a void > > > > If anybody can think of any more checks that are required let me know. > > > > Oh, and here are the warning messages printed for cases 2 and 3 > respectively, > > again, if somebody has a better descriptive string or with better > english I'll > > change it: > > > > 2) "'%0' attribute only applies to functions with no arguments" > > 3) "'%0' attribute only applies to functions with a void return type" > > where %0 is either interrupt or signal > > > > > Semantics question: Do you mean that it issues just a *warning*? Or does > it error out on these? > > |
|
From: Borja F. <bor...@gm...> - 2012-03-06 19:22:08
|
It issues a warning, so, it doesn't apply the attribute and it doesn't abort compilation. I checked gcc and it warns aswell. However i can error out if it's better, i leave that up to you. 2012/3/6 Weddington, Eric <Eri...@at...> > > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Tuesday, March 06, 2012 11:57 AM > > To: Weddington, Eric > > Cc: avr...@li... > > Subject: Re: [avr-llvm-devel] Interrupt handling > > > > I've added some checks to the frontend when setting the > signal/interrupt > > attribute that are the following: > > > > 1) warn when the attrib is used in things that aren't function > declarations. > > 2) warn when the function has arguments > > 3) warn when the function doesnt return a void > > > > If anybody can think of any more checks that are required let me know. > > > > Oh, and here are the warning messages printed for cases 2 and 3 > respectively, > > again, if somebody has a better descriptive string or with better > english I'll > > change it: > > > > 2) "'%0' attribute only applies to functions with no arguments" > > 3) "'%0' attribute only applies to functions with a void return type" > > where %0 is either interrupt or signal > > > > Semantics question: Do you mean that it issues just a *warning*? Or does > it error out on these? > |
|
From: Weddington, E. <Eri...@at...> - 2012-03-06 19:05:36
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Tuesday, March 06, 2012 11:57 AM > To: Weddington, Eric > Cc: avr...@li... > Subject: Re: [avr-llvm-devel] Interrupt handling > > I've added some checks to the frontend when setting the signal/interrupt > attribute that are the following: > > 1) warn when the attrib is used in things that aren't function declarations. > 2) warn when the function has arguments > 3) warn when the function doesnt return a void > > If anybody can think of any more checks that are required let me know. > > Oh, and here are the warning messages printed for cases 2 and 3 respectively, > again, if somebody has a better descriptive string or with better english I'll > change it: > > 2) "'%0' attribute only applies to functions with no arguments" > 3) "'%0' attribute only applies to functions with a void return type" > where %0 is either interrupt or signal > Semantics question: Do you mean that it issues just a *warning*? Or does it error out on these? |
|
From: Borja F. <bor...@gm...> - 2012-03-06 18:56:42
|
I've added some checks to the frontend when setting the signal/interrupt attribute that are the following: 1) warn when the attrib is used in things that aren't function declarations. 2) warn when the function has arguments 3) warn when the function doesnt return a void If anybody can think of any more checks that are required let me know. Oh, and here are the warning messages printed for cases 2 and 3 respectively, again, if somebody has a better descriptive string or with better english I'll change it: 2) "'%0' attribute only applies to functions with no arguments" 3) "'%0' attribute only applies to functions with a void return type" where %0 is either interrupt or signal 2012/3/6 Borja Ferrer <bor...@gm...> > Heh ok :) that's why I did the truth table above, because some attributes > override others and we want to have the same behaviour as gcc. Now that > everything is clear I'll implement this next. > > Btw, I've already fixed the case of not emitting ret/reti when naked is > present. > > 2012/3/6 Weddington, Eric <Eri...@at...> > > >> >> > -----Original Message----- >> > From: Borja Ferrer [mailto:bor...@gm...] >> > Sent: Monday, March 05, 2012 5:43 PM >> > To: Weddington, Eric >> > Cc: avr...@li... >> > Subject: Re: [avr-llvm-devel] Interrupt handling >> > >> > >> > #define ISR(vector, ...) \ >> > void vector (void) __attribute__ ((signal,__INTR_ATTRS)) >> __VA_ARGS__; \ >> > void vector (void) >> > # define ISR_NOBLOCK __attribute__((interrupt)) >> > >> > >> >> Hmm. Yeah, ok, you're correct about that. I forgot about all that stuff >> that was added to avr-libc. >> >> So, in this case, the "interrupt" attribute overrides "signal". >> >> I think you're good to go now. :-) >> >> Eric >> > > |
|
From: Borja F. <bor...@gm...> - 2012-03-06 11:22:50
|
Heh ok :) that's why I did the truth table above, because some attributes override others and we want to have the same behaviour as gcc. Now that everything is clear I'll implement this next. Btw, I've already fixed the case of not emitting ret/reti when naked is present. 2012/3/6 Weddington, Eric <Eri...@at...> > > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Monday, March 05, 2012 5:43 PM > > To: Weddington, Eric > > Cc: avr...@li... > > Subject: Re: [avr-llvm-devel] Interrupt handling > > > > > > #define ISR(vector, ...) \ > > void vector (void) __attribute__ ((signal,__INTR_ATTRS)) > __VA_ARGS__; \ > > void vector (void) > > # define ISR_NOBLOCK __attribute__((interrupt)) > > > > > > Hmm. Yeah, ok, you're correct about that. I forgot about all that stuff > that was added to avr-libc. > > So, in this case, the "interrupt" attribute overrides "signal". > > I think you're good to go now. :-) > > Eric > |
|
From: Weddington, E. <Eri...@at...> - 2012-03-06 05:05:07
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Monday, March 05, 2012 5:43 PM > To: Weddington, Eric > Cc: avr...@li... > Subject: Re: [avr-llvm-devel] Interrupt handling > > > #define ISR(vector, ...) \ > void vector (void) __attribute__ ((signal,__INTR_ATTRS)) __VA_ARGS__; \ > void vector (void) > # define ISR_NOBLOCK __attribute__((interrupt)) > > Hmm. Yeah, ok, you're correct about that. I forgot about all that stuff that was added to avr-libc. So, in this case, the "interrupt" attribute overrides "signal". I think you're good to go now. :-) Eric |
|
From: Borja F. <bor...@gm...> - 2012-03-06 00:43:25
|
Ok lets go by parts:
I will fix the naked attribute to not emit the ret/reti instructions. I
don't know in gcc, but in llvm the ret instruction is inserted very early,
not during prologue/epilogue insertion, that's why it's getting emitted by
default. So additional code has to be added to handle this. Yes, I've tried
naked in non ISR functions aswell so I knew it was something valid to do. I
wasn't sure about how it worked in combination with other attributes.
About the interrupt and signal attributes, i think it should be possible to
error out if they're both defined. But looking in avr-libc's code when you
add the ISR_NOBLOCK macro inside the ISR macro you're both defining signal
and interrupt at the same time, so it would always error out, or am I
missing something?
#define ISR(vector, ...) \
void vector (void) __attribute__ ((signal,__INTR_ATTRS)) __VA_ARGS__; \
void vector (void)
# define ISR_NOBLOCK __attribute__((interrupt))
2012/3/5 Weddington, Eric <Eri...@at...>
> Hi Borja,
>
> From my view, "interrupt" and "signal" are mutually exclusive. They both
> define an ISR, where "interrupt" allows nested interrupts and "signal"
> disallows nested interrupts.
>
> I don't know if we can error out if a user defines both simultaneously.
>
> "naked" does something completely different than interrupt|signal. One
> can have a naked function without it being an ISR.
>
> Can one have a "naked" ISR? I suppose if one is writing the ISR in
> assembly... Another reason to have interrupt|signal is to put that
> function into the IVT. So, yes, the combination is valid, but naked
> should have priority, and the prologue/epilogue should not be generated
> for that ISR, and it is up to the user to write.
>
> Technically, the RET/RETI is usually a part of the epilogue. Naked
> functions do not have prologues/epilogues, hence, they do not have a
> RET/RETI, and the user has to provide those.
>
> Hope that answers any questions. Again, my only suggestion would be to
> error out on simultaneous "interrupt" and "signal" attributes.
>
> Eric Weddington
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Monday, March 05, 2012 1:58 PM
> > To: avr...@li...
> > Subject: [avr-llvm-devel] Interrupt handling
> >
> > I'm currently implementing support for interrupt handling. But before
> going
> > any further into implementing it in the backend (the frontend part is
> nearly
> > done) I want to get things clear. Eric this one is probably for you
> because
> > it's about avr-libc but anyways, here we go:
> >
> > There are 2 function attributes to add:
> >
> > 1) signal (ISR macro): normal interrupt handler. Every register used
> inside
> > the handler gets saved in the stack, including special code to save
> SREG. So
> > we have to mark all registers to be callee saved.
> > 2) interrupt (ISR_NOBLOCK): same as above but adding a sei instruction
> at the
> > very top of function entry.
> >
> > Now, the naked attribute is already implemented and i don't need to
> handle
> > anything with it. It avoids any prologue/epilogue code to be inserted.
> BUT by
> > default the ret/reti instruction gets emitted, and avr-libc says that
> it
> > should be done by the programmer so I have to handle that, right?
> > This doesn't matter if it's an ISR or a normal func.
> >
> > The ISR_ALIASOF macro works correctly, so no more work is needed there
> (using
> > NOBLOCK or NAKED with ALIASOF doesn't make sense at all, right?)
> >
> > Now i want to talk about combining attributes:
> > Truth table format: |signal | interrupt | naked|
> >
> > 1) 0 0 0 -> nothing
> >
> > 2) 0 0 1 -> no prologue/epilogue and no ret/reti (used in any
> arbitrary
> > function)(so as i said before, don't emit ret/reti?)
> >
> > 3) 0 1 0 -> emit sei, and save all used regs inside the function plus
> SREG.
> >
> > 4) 0 1 1 -> naked wins, do case 1.
> >
> > 5) 1 0 0 -> normal ISR macro, do what i said when explaining the
> signal
> > attrib.
> >
> > 6) 1 0 1 -> naked wins again.
> >
> > 7) 1 1 0 -> interrupt wins, do case 3.
> >
> > 8) 1 1 1 -> naked wins.
> >
> > So this is what I understand I have to do, please let me know if I'm
> wrong on
> > anything I've mentioned.
> >
>
>
|
|
From: Weddington, E. <Eri...@at...> - 2012-03-05 21:39:11
|
Hi Borja, >From my view, "interrupt" and "signal" are mutually exclusive. They both define an ISR, where "interrupt" allows nested interrupts and "signal" disallows nested interrupts. I don't know if we can error out if a user defines both simultaneously. "naked" does something completely different than interrupt|signal. One can have a naked function without it being an ISR. Can one have a "naked" ISR? I suppose if one is writing the ISR in assembly... Another reason to have interrupt|signal is to put that function into the IVT. So, yes, the combination is valid, but naked should have priority, and the prologue/epilogue should not be generated for that ISR, and it is up to the user to write. Technically, the RET/RETI is usually a part of the epilogue. Naked functions do not have prologues/epilogues, hence, they do not have a RET/RETI, and the user has to provide those. Hope that answers any questions. Again, my only suggestion would be to error out on simultaneous "interrupt" and "signal" attributes. Eric Weddington > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Monday, March 05, 2012 1:58 PM > To: avr...@li... > Subject: [avr-llvm-devel] Interrupt handling > > I'm currently implementing support for interrupt handling. But before going > any further into implementing it in the backend (the frontend part is nearly > done) I want to get things clear. Eric this one is probably for you because > it's about avr-libc but anyways, here we go: > > There are 2 function attributes to add: > > 1) signal (ISR macro): normal interrupt handler. Every register used inside > the handler gets saved in the stack, including special code to save SREG. So > we have to mark all registers to be callee saved. > 2) interrupt (ISR_NOBLOCK): same as above but adding a sei instruction at the > very top of function entry. > > Now, the naked attribute is already implemented and i don't need to handle > anything with it. It avoids any prologue/epilogue code to be inserted. BUT by > default the ret/reti instruction gets emitted, and avr-libc says that it > should be done by the programmer so I have to handle that, right? > This doesn't matter if it's an ISR or a normal func. > > The ISR_ALIASOF macro works correctly, so no more work is needed there (using > NOBLOCK or NAKED with ALIASOF doesn't make sense at all, right?) > > Now i want to talk about combining attributes: > Truth table format: |signal | interrupt | naked| > > 1) 0 0 0 -> nothing > > 2) 0 0 1 -> no prologue/epilogue and no ret/reti (used in any arbitrary > function)(so as i said before, don't emit ret/reti?) > > 3) 0 1 0 -> emit sei, and save all used regs inside the function plus SREG. > > 4) 0 1 1 -> naked wins, do case 1. > > 5) 1 0 0 -> normal ISR macro, do what i said when explaining the signal > attrib. > > 6) 1 0 1 -> naked wins again. > > 7) 1 1 0 -> interrupt wins, do case 3. > > 8) 1 1 1 -> naked wins. > > So this is what I understand I have to do, please let me know if I'm wrong on > anything I've mentioned. > |
|
From: Borja F. <bor...@gm...> - 2012-03-05 21:11:32
|
Ah John one more thing, you may want to combine SelectionDAGBuilder.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/SelectionDAGBuilder.diff?sortby=date&view=log>and TargetCallingConv.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/TargetCallingConv.diff?sortby=date&view=log>into one file since they both are used for the same purpose, you can name the patch SplitArgPiece 2012/3/5 Borja Ferrer <bor...@gm...> > For now, spload should be the only pseudo that is allowed to get into > assembly, if you see any other pseudo it is a bug. Expanding spload into > real instructions requires a bit of work that is currently unimplemented, > so for now we'll have to live with it. I hope it's not a big deal for you. > > About the patches, it's a good idea what you said, feel free to do it when > you have time. I still have to add some more patches about interrupts. > > > 2012/3/5 John Myers <ato...@gm...> > >> On Sun, Mar 4, 2012 at 1:33 PM, Borja Ferrer <bor...@gm...>wrote: >> >>> John check the lastest patch files I've just commited to see if they >>> patch correctly or i've messed them. >>> Btw, have you been able to try the backend? >>> >> >> They all apply cleanly but you have to hunt around to find which >> directory to start in for each file. I'm going to combine them into one >> patch that can be applied from the root directory. >> >> >> I haven't really looked at the backend yet . I did notice that there was >> a pseudo instruction (spload) that made it into the assembly file which >> stopped avr-gcc from being able to assemble it though. >> >> main: >> push r28 >> push r29 >> spload r29:r28, SP >> sbiw r29:r28, 2 >> ldi r24, 0 >> ldi r25, 0 >> std Y+1, r24 >> std Y+2, r25 >> spload r29:r28, SP >> adiw r29:r28, 2 >> pop r29 >> pop r28 >> ret >> >> > |
|
From: Borja F. <bor...@gm...> - 2012-03-05 20:57:38
|
I'm currently implementing support for interrupt handling. But before going any further into implementing it in the backend (the frontend part is nearly done) I want to get things clear. Eric this one is probably for you because it's about avr-libc but anyways, here we go: There are 2 function attributes to add: 1) signal (ISR macro): normal interrupt handler. Every register used inside the handler gets saved in the stack, including special code to save SREG. So we have to mark all registers to be callee saved. 2) interrupt (ISR_NOBLOCK): same as above but adding a sei instruction at the very top of function entry. Now, the naked attribute is already implemented and i don't need to handle anything with it. It avoids any prologue/epilogue code to be inserted. BUT by default the ret/reti instruction gets emitted, and avr-libc says that it should be done by the programmer so I have to handle that, right? This doesn't matter if it's an ISR or a normal func. The ISR_ALIASOF macro works correctly, so no more work is needed there (using NOBLOCK or NAKED with ALIASOF doesn't make sense at all, right?) Now i want to talk about combining attributes: Truth table format: |signal | interrupt | naked| 1) 0 0 0 -> nothing 2) 0 0 1 -> no prologue/epilogue and no ret/reti (used in any arbitrary function)(so as i said before, don't emit ret/reti?) 3) 0 1 0 -> emit sei, and save all used regs inside the function plus SREG. 4) 0 1 1 -> naked wins, do case 1. 5) 1 0 0 -> normal ISR macro, do what i said when explaining the signal attrib. 6) 1 0 1 -> naked wins again. 7) 1 1 0 -> interrupt wins, do case 3. 8) 1 1 1 -> naked wins. So this is what I understand I have to do, please let me know if I'm wrong on anything I've mentioned. |
|
From: Borja F. <bor...@gm...> - 2012-03-05 20:25:50
|
For now, spload should be the only pseudo that is allowed to get into assembly, if you see any other pseudo it is a bug. Expanding spload into real instructions requires a bit of work that is currently unimplemented, so for now we'll have to live with it. I hope it's not a big deal for you. About the patches, it's a good idea what you said, feel free to do it when you have time. I still have to add some more patches about interrupts. 2012/3/5 John Myers <ato...@gm...> > On Sun, Mar 4, 2012 at 1:33 PM, Borja Ferrer <bor...@gm...>wrote: > >> John check the lastest patch files I've just commited to see if they >> patch correctly or i've messed them. >> Btw, have you been able to try the backend? >> > > They all apply cleanly but you have to hunt around to find which directory > to start in for each file. I'm going to combine them into one patch that > can be applied from the root directory. > > > I haven't really looked at the backend yet . I did notice that there was a > pseudo instruction (spload) that made it into the assembly file which > stopped avr-gcc from being able to assemble it though. > > main: > push r28 > push r29 > spload r29:r28, SP > sbiw r29:r28, 2 > ldi r24, 0 > ldi r25, 0 > std Y+1, r24 > std Y+2, r25 > spload r29:r28, SP > adiw r29:r28, 2 > pop r29 > pop r28 > ret > > |
|
From: John M. <ato...@gm...> - 2012-03-05 00:40:05
|
On Sun, Mar 4, 2012 at 1:33 PM, Borja Ferrer <bor...@gm...> wrote:
> John check the lastest patch files I've just commited to see if they patch
> correctly or i've messed them.
> Btw, have you been able to try the backend?
>
They all apply cleanly but you have to hunt around to find which directory
to start in for each file. I'm going to combine them into one patch that
can be applied from the root directory.
I haven't really looked at the backend yet . I did notice that there was a
pseudo instruction (spload) that made it into the assembly file which
stopped avr-gcc from being able to assemble it though.
main:
push r28
push r29
spload r29:r28, SP
sbiw r29:r28, 2
ldi r24, 0
ldi r25, 0
std Y+1, r24
std Y+2, r25
spload r29:r28, SP
adiw r29:r28, 2
pop r29
pop r28
ret
|
|
From: Borja F. <bor...@gm...> - 2012-03-04 21:34:05
|
John check the lastest patch files I've just commited to see if they patch correctly or i've messed them. Btw, have you been able to try the backend? 2012/3/4 Borja Ferrer <bor...@gm...> > John, can you update the RegAllocGreedy patch file with last night > changes? You have to change the AliasI variable in the for loop to be of > type uint16_t * instead of unsigned *. > > > 2012/2/26 Borja Ferrer <bor...@gm...> > >> Ok, fixed. This was caused by rev151134 where they changed the format on >> how register classes are printed with tablegen, making RC a const pointer. >> >> >> 2012/2/26 Borja Ferrer <bor...@gm...> >> >>> I don't think so John, I'll take a look. This compiled last week when I >>> committed it perfectly so maybe there's been some change during this week >>> than has broken the build. I assume this happens to you with latest LLVM >>> trunk revision? >>> >>> >>> 2012/2/26 John Myers <ato...@gm...> >>> >>>> >>>> >>>> On Wed, Feb 22, 2012 at 4:34 PM, Borja Ferrer <bor...@gm...>wrote: >>>> >>>>> No comments yet? >>>>> >>>> >>>> I'm getting the below error. Are there other patches that haven't been >>>> committed or is this just a mis-match between the LLVM trunk and avr-llvm? >>>> >>>> llvm[3]: Compiling AVRFrameLowering.cpp for Release+Asserts build >>>> llvm[3]: Compiling AVRISelDAGToDAG.cpp for Release+Asserts build >>>> llvm[3]: Compiling AVRISelLowering.cpp for Release+Asserts build >>>> AVRISelLowering.cpp:762:12: error: assigning to >>>> 'llvm::TargetRegisterClass *' from incompatible type 'const >>>> llvm::TargetRegisterClass *const' >>>> RC = AVR::GPR8RegisterClass; >>>> ^ ~~~~~~~~~~~~~~~~~~~~~~ >>>> AVRISelLowering.cpp:766:12: error: assigning to >>>> 'llvm::TargetRegisterClass *' from incompatible type 'const >>>> llvm::TargetRegisterClass *const' >>>> RC = AVR::DREGSRegisterClass; >>>> ^ ~~~~~~~~~~~~~~~~~~~~~~~ >>>> 2 errors generated. >>>> >>>> >>> >> > |
|
From: Borja F. <bor...@gm...> - 2012-03-04 13:35:22
|
John, can you update the RegAllocGreedy patch file with last night changes? You have to change the AliasI variable in the for loop to be of type uint16_t * instead of unsigned *. 2012/2/26 Borja Ferrer <bor...@gm...> > Ok, fixed. This was caused by rev151134 where they changed the format on > how register classes are printed with tablegen, making RC a const pointer. > > > 2012/2/26 Borja Ferrer <bor...@gm...> > >> I don't think so John, I'll take a look. This compiled last week when I >> committed it perfectly so maybe there's been some change during this week >> than has broken the build. I assume this happens to you with latest LLVM >> trunk revision? >> >> >> 2012/2/26 John Myers <ato...@gm...> >> >>> >>> >>> On Wed, Feb 22, 2012 at 4:34 PM, Borja Ferrer <bor...@gm...>wrote: >>> >>>> No comments yet? >>>> >>> >>> I'm getting the below error. Are there other patches that haven't been >>> committed or is this just a mis-match between the LLVM trunk and avr-llvm? >>> >>> llvm[3]: Compiling AVRFrameLowering.cpp for Release+Asserts build >>> llvm[3]: Compiling AVRISelDAGToDAG.cpp for Release+Asserts build >>> llvm[3]: Compiling AVRISelLowering.cpp for Release+Asserts build >>> AVRISelLowering.cpp:762:12: error: assigning to >>> 'llvm::TargetRegisterClass *' from incompatible type 'const >>> llvm::TargetRegisterClass *const' >>> RC = AVR::GPR8RegisterClass; >>> ^ ~~~~~~~~~~~~~~~~~~~~~~ >>> AVRISelLowering.cpp:766:12: error: assigning to >>> 'llvm::TargetRegisterClass *' from incompatible type 'const >>> llvm::TargetRegisterClass *const' >>> RC = AVR::DREGSRegisterClass; >>> ^ ~~~~~~~~~~~~~~~~~~~~~~~ >>> 2 errors generated. >>> >>> >> > |
|
From: Borja F. <bor...@gm...> - 2012-02-26 14:38:56
|
Ok, fixed. This was caused by rev151134 where they changed the format on how register classes are printed with tablegen, making RC a const pointer. 2012/2/26 Borja Ferrer <bor...@gm...> > I don't think so John, I'll take a look. This compiled last week when I > committed it perfectly so maybe there's been some change during this week > than has broken the build. I assume this happens to you with latest LLVM > trunk revision? > > > 2012/2/26 John Myers <ato...@gm...> > >> >> >> On Wed, Feb 22, 2012 at 4:34 PM, Borja Ferrer <bor...@gm...>wrote: >> >>> No comments yet? >>> >> >> I'm getting the below error. Are there other patches that haven't been >> committed or is this just a mis-match between the LLVM trunk and avr-llvm? >> >> llvm[3]: Compiling AVRFrameLowering.cpp for Release+Asserts build >> llvm[3]: Compiling AVRISelDAGToDAG.cpp for Release+Asserts build >> llvm[3]: Compiling AVRISelLowering.cpp for Release+Asserts build >> AVRISelLowering.cpp:762:12: error: assigning to >> 'llvm::TargetRegisterClass *' from incompatible type 'const >> llvm::TargetRegisterClass *const' >> RC = AVR::GPR8RegisterClass; >> ^ ~~~~~~~~~~~~~~~~~~~~~~ >> AVRISelLowering.cpp:766:12: error: assigning to >> 'llvm::TargetRegisterClass *' from incompatible type 'const >> llvm::TargetRegisterClass *const' >> RC = AVR::DREGSRegisterClass; >> ^ ~~~~~~~~~~~~~~~~~~~~~~~ >> 2 errors generated. >> >> > |
|
From: Borja F. <bor...@gm...> - 2012-02-26 14:00:58
|
I don't think so John, I'll take a look. This compiled last week when I committed it perfectly so maybe there's been some change during this week than has broken the build. I assume this happens to you with latest LLVM trunk revision? 2012/2/26 John Myers <ato...@gm...> > > > On Wed, Feb 22, 2012 at 4:34 PM, Borja Ferrer <bor...@gm...>wrote: > >> No comments yet? >> > > I'm getting the below error. Are there other patches that haven't been > committed or is this just a mis-match between the LLVM trunk and avr-llvm? > > llvm[3]: Compiling AVRFrameLowering.cpp for Release+Asserts build > llvm[3]: Compiling AVRISelDAGToDAG.cpp for Release+Asserts build > llvm[3]: Compiling AVRISelLowering.cpp for Release+Asserts build > AVRISelLowering.cpp:762:12: error: assigning to 'llvm::TargetRegisterClass > *' from incompatible type 'const llvm::TargetRegisterClass *const' > RC = AVR::GPR8RegisterClass; > ^ ~~~~~~~~~~~~~~~~~~~~~~ > AVRISelLowering.cpp:766:12: error: assigning to 'llvm::TargetRegisterClass > *' from incompatible type 'const llvm::TargetRegisterClass *const' > RC = AVR::DREGSRegisterClass; > ^ ~~~~~~~~~~~~~~~~~~~~~~~ > 2 errors generated. > > |
|
From: John M. <ato...@gm...> - 2012-02-26 04:37:40
|
On Wed, Feb 22, 2012 at 4:34 PM, Borja Ferrer <bor...@gm...> wrote:
> No comments yet?
>
I'm getting the below error. Are there other patches that haven't been
committed or is this just a mis-match between the LLVM trunk and avr-llvm?
llvm[3]: Compiling AVRFrameLowering.cpp for Release+Asserts build
llvm[3]: Compiling AVRISelDAGToDAG.cpp for Release+Asserts build
llvm[3]: Compiling AVRISelLowering.cpp for Release+Asserts build
AVRISelLowering.cpp:762:12: error: assigning to 'llvm::TargetRegisterClass
*' from incompatible type 'const llvm::TargetRegisterClass *const'
RC = AVR::GPR8RegisterClass;
^ ~~~~~~~~~~~~~~~~~~~~~~
AVRISelLowering.cpp:766:12: error: assigning to 'llvm::TargetRegisterClass
*' from incompatible type 'const llvm::TargetRegisterClass *const'
RC = AVR::DREGSRegisterClass;
^ ~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
|
|
From: Borja F. <bor...@gm...> - 2012-02-23 00:34:26
|
No comments yet? 2012/2/18 Borja Ferrer <bor...@gm...> > I've just committed the new backend code to SVN. Please let me know any > thoughts about it. > > > 2012/2/13 Borja Ferrer <bor...@gm...> > >> Ok then, I'll update all cmakelist files. >> >> 2012/2/13 Weddington, Eric <Eri...@at...> >> >> >>> >>> > -----Original Message----- >>> > From: Borja Ferrer [mailto:bor...@gm...] >>> > Sent: Saturday, February 11, 2012 2:19 PM >>> > To: Weddington, Eric >>> > Cc: Sherard Dames; avr...@li... >>> > Subject: Re: [avr-llvm-devel] Current Status? >>> > >>> > Not yet but, I've just finished implementing basic support for >>> branching and >>> > selects. So, before commiting I'm going to update my code to compile >>> with >>> > latest llvm's trunk and then i will finally upload the code. Btw, is >>> anybody >>> > here that is going to compile the code in windows? If yes, I will >>> update the >>> > cmakelist files. >>> >>> I'm definitely interested in having avr-llvm run on windows. >>> >> >> > |
|
From: Borja F. <bor...@gm...> - 2012-02-18 02:02:42
|
I've just committed the new backend code to SVN. Please let me know any thoughts about it. 2012/2/13 Borja Ferrer <bor...@gm...> > Ok then, I'll update all cmakelist files. > > 2012/2/13 Weddington, Eric <Eri...@at...> > > >> >> > -----Original Message----- >> > From: Borja Ferrer [mailto:bor...@gm...] >> > Sent: Saturday, February 11, 2012 2:19 PM >> > To: Weddington, Eric >> > Cc: Sherard Dames; avr...@li... >> > Subject: Re: [avr-llvm-devel] Current Status? >> > >> > Not yet but, I've just finished implementing basic support for >> branching and >> > selects. So, before commiting I'm going to update my code to compile >> with >> > latest llvm's trunk and then i will finally upload the code. Btw, is >> anybody >> > here that is going to compile the code in windows? If yes, I will >> update the >> > cmakelist files. >> >> I'm definitely interested in having avr-llvm run on windows. >> > > |
|
From: Weddington, E. <Eri...@at...> - 2012-02-14 03:51:18
|
> -----Original Message----- > From: Neil Funk [mailto:inf...@gm...] > Sent: Monday, February 13, 2012 5:10 PM > To: avr...@li... > Subject: Re: [avr-llvm-devel] avr-llvm-devel Digest, Vol 14, Issue 2 > > I'm interested in helping out. I'm working on a Scheme->LLVM compiler > front-end, and would eventually like to be able to use a dialect of > scheme to reach all the way through to the AVR on the back-end. > (Think ISRs as lambdas, etc.) Weird? Maybe. But I'm interested in > helping out. (My interest is Linux-only, BTW.) > -Neil Cool! :-) It's ok if you're only interested in having it for the Linux platform. It's cross-platform, so we're all ok. But it would be neat to be able to tell people that they can write Scheme for the AVR. ;-) Eric Weddington |
|
From: Neil F. <inf...@gm...> - 2012-02-14 00:10:49
|
I'm interested in helping out. I'm working on a Scheme->LLVM compiler front-end, and would eventually like to be able to use a dialect of scheme to reach all the way through to the AVR on the back-end. (Think ISRs as lambdas, etc.) Weird? Maybe. But I'm interested in helping out. (My interest is Linux-only, BTW.) -Neil On Mon, Feb 13, 2012 at 1:03 PM, <avr...@li...> wrote: > Send avr-llvm-devel mailing list submissions to > avr...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > or, via email, send a message with subject or body 'help' to > avr...@li... > > You can reach the person managing the list at > avr...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of avr-llvm-devel digest..." > > > Today's Topics: > > 1. Re: Current Status? (Weddington, Eric) > 2. Re: Current Status? (Borja Ferrer) > 3. Re: Current Status? (Weddington, Eric) > 4. Re: Current Status? (Borja Ferrer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 3 Feb 2012 12:01:51 -0700 > From: "Weddington, Eric" <Eri...@at...> > Subject: Re: [avr-llvm-devel] Current Status? > To: "Borja Ferrer" <bor...@gm...> > Cc: avr...@li... > Message-ID: > <8D6...@cs...> > Content-Type: text/plain; charset="us-ascii" > > Hi Borja, > > Do you have any of your work committed yet? There are other people > interested in helping, but we need to have the latest in the repo... > > Eric > >> -----Original Message----- >> From: Borja Ferrer [mailto:bor...@gm...] >> Sent: Friday, February 03, 2012 9:10 AM >> To: Weddington, Eric >> Cc: Sherard Dames; avr...@li... >> Subject: Re: [avr-llvm-devel] Current Status? >> >> Ahh ok, I will take a look then. >> >> Update: I've already implemented conditional branches for if() > conditions >> (BR_CC node). I still need to work on overriding some virtual > functions in >> some interfaces to improve the generated code. Then I will move to > SETCC and >> SELECT nodes which are used in things like: a = (b > c) and a = (b > > c) ? 1 : >> 2 respectively. >> I'm happy because we can now compile loops :) >> >> >> 2012/1/31 Weddington, Eric <Eri...@at...> >> >> >> Hi Borja, >> >> Thanks for the ping. >> >> Unfortunately the best place to see how address spaces work is > still the >> GCC source code, and documentation :-( >> >> Eric >> >> >> > -----Original Message----- >> > From: Borja Ferrer [mailto:bor...@gm...] >> >> > Sent: Tuesday, January 31, 2012 7:08 AM >> > To: Weddington, Eric >> > Cc: Sherard Dames; avr...@li... >> > Subject: Re: [avr-llvm-devel] Current Status? >> > >> > Update: I've already started working on conditional branches > and >> compares. >> > Eric ping? >> > >> > >> > 2012/1/20 Borja Ferrer <bor...@gm...> >> > >> > >> > Ahh ok thanks for the info Eric, about the work on > doubles, what >> sort of >> > support is it? shouldn't that go into write the math functions > in the >> C >> > library? or do you mean removing the constraint of making > double a >> float? >> > Is there a place on how the multiple address space > feature will >> work, we >> > should implement this aswell in an early stage so it's > important that >> we see >> > how it works to be compatible with what gcc does. >> > >> > >> > 2012/1/16 Weddington, Eric <Eri...@at...> >> > >> > >> > >> > >> > >> > > -----Original Message----- >> > > From: Borja Ferrer > [mailto:bor...@gm...] >> > >> > > Sent: Friday, January 13, 2012 9:19 AM >> > > To: Weddington, Eric >> > > Cc: Sherard Dames; >> avr...@li... >> > > Subject: Re: [avr-llvm-devel] Current Status? >> > > >> > >> > > Eric one more thing, you mentioned that some > work has >> been done >> > lately >> > in >> > > gcc's backend, can you tell me what are the > main >> features added >> > and if >> > > there are any code quality improvements. >> > >> > >> > Umpf. There's been so much happening, I'm not > sure if I >> can >> > remember it >> > all >> > >> > - Improvements in the AVR backend, especially a > number >> of missed >> > optimization bugs fixed >> > >> > - The beginning of a Multiple Address Spaces > feature >> > >> > - The beginning of 24-bit types, mainly used for >> Multiple Address >> > Spaces >> > (i.e. large code space, or large data space) >> > >> > - Some work done on 64-bit double types >> > >> > And other fixed bugs. >> > >> > Eric >> > >> > >> > >> >> >> > > > > > ------------------------------ > > Message: 2 > Date: Sat, 11 Feb 2012 22:18:40 +0100 > From: Borja Ferrer <bor...@gm...> > Subject: Re: [avr-llvm-devel] Current Status? > To: "Weddington, Eric" <Eri...@at...> > Cc: avr...@li... > Message-ID: > <CAMOECut++2AqdVcr4ktgzQRccCaP3B607Gqkn=jBw...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > Not yet but, I've just finished implementing basic support for branching > and selects. So, before commiting I'm going to update my code to compile > with latest llvm's trunk and then i will finally upload the code. Btw, is > anybody here that is going to compile the code in windows? If yes, I will > update the cmakelist files. > > 2012/2/3 Weddington, Eric <Eri...@at...> > >> Hi Borja, >> >> Do you have any of your work committed yet? There are other people >> interested in helping, but we need to have the latest in the repo... >> >> Eric >> >> > -----Original Message----- >> > From: Borja Ferrer [mailto:bor...@gm...] >> > Sent: Friday, February 03, 2012 9:10 AM >> > To: Weddington, Eric >> > Cc: Sherard Dames; avr...@li... >> > Subject: Re: [avr-llvm-devel] Current Status? >> > >> > Ahh ok, I will take a look then. >> > >> > Update: I've already implemented conditional branches for if() >> conditions >> > (BR_CC node). I still need to work on overriding some virtual >> functions in >> > some interfaces to improve the generated code. Then I will move to >> SETCC and >> > SELECT nodes which are used in things like: a = (b > c) and a = (b > >> c) ? 1 : >> > 2 respectively. >> > I'm happy because we can now compile loops :) >> > >> > >> > 2012/1/31 Weddington, Eric <Eri...@at...> >> > >> > >> > Hi Borja, >> > >> > Thanks for the ping. >> > >> > Unfortunately the best place to see how address spaces work is >> still the >> > GCC source code, and documentation :-( >> > >> > Eric >> > >> > >> > > -----Original Message----- >> > > From: Borja Ferrer [mailto:bor...@gm...] >> > >> > > Sent: Tuesday, January 31, 2012 7:08 AM >> > > To: Weddington, Eric >> > > Cc: Sherard Dames; avr...@li... >> > > Subject: Re: [avr-llvm-devel] Current Status? >> > > >> > > Update: I've already started working on conditional branches >> and >> > compares. >> > > Eric ping? >> > > >> > > >> > > 2012/1/20 Borja Ferrer <bor...@gm...> >> > > >> > > >> > > Ahh ok thanks for the info Eric, about the work on >> doubles, what >> > sort of >> > > support is it? shouldn't that go into write the math functions >> in the >> > C >> > > library? or do you mean removing the constraint of making >> double a >> > float? >> > > Is there a place on how the multiple address space >> feature will >> > work, we >> > > should implement this aswell in an early stage so it's >> important that >> > we see >> > > how it works to be compatible with what gcc does. >> > > >> > > >> > > 2012/1/16 Weddington, Eric <Eri...@at...> >> > > >> > > >> > > >> > > >> > > >> > > > -----Original Message----- >> > > > From: Borja Ferrer >> [mailto:bor...@gm...] >> > > >> > > > Sent: Friday, January 13, 2012 9:19 AM >> > > > To: Weddington, Eric >> > > > Cc: Sherard Dames; >> > avr...@li... >> > > > Subject: Re: [avr-llvm-devel] Current Status? >> > > > >> > > >> > > > Eric one more thing, you mentioned that some >> work has >> > been done >> > > lately >> > > in >> > > > gcc's backend, can you tell me what are the >> main >> > features added >> > > and if >> > > > there are any code quality improvements. >> > > >> > > >> > > Umpf. There's been so much happening, I'm not >> sure if I >> > can >> > > remember it >> > > all >> > > >> > > - Improvements in the AVR backend, especially a >> number >> > of missed >> > > optimization bugs fixed >> > > >> > > - The beginning of a Multiple Address Spaces >> feature >> > > >> > > - The beginning of 24-bit types, mainly used for >> > Multiple Address >> > > Spaces >> > > (i.e. large code space, or large data space) >> > > >> > > - Some work done on 64-bit double types >> > > >> > > And other fixed bugs. >> > > >> > > Eric >> > > >> > > >> > > >> > >> > >> > >> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 3 > Date: Mon, 13 Feb 2012 10:40:12 -0700 > From: "Weddington, Eric" <Eri...@at...> > Subject: Re: [avr-llvm-devel] Current Status? > To: "Borja Ferrer" <bor...@gm...> > Cc: avr...@li... > Message-ID: > <8D6...@cs...> > Content-Type: text/plain; charset="us-ascii" > > > >> -----Original Message----- >> From: Borja Ferrer [mailto:bor...@gm...] >> Sent: Saturday, February 11, 2012 2:19 PM >> To: Weddington, Eric >> Cc: Sherard Dames; avr...@li... >> Subject: Re: [avr-llvm-devel] Current Status? >> >> Not yet but, I've just finished implementing basic support for > branching and >> selects. So, before commiting I'm going to update my code to compile > with >> latest llvm's trunk and then i will finally upload the code. Btw, is > anybody >> here that is going to compile the code in windows? If yes, I will > update the >> cmakelist files. > > I'm definitely interested in having avr-llvm run on windows. > > > > ------------------------------ > > Message: 4 > Date: Mon, 13 Feb 2012 19:03:09 +0100 > From: Borja Ferrer <bor...@gm...> > Subject: Re: [avr-llvm-devel] Current Status? > To: "Weddington, Eric" <Eri...@at...> > Cc: avr...@li... > Message-ID: > <CAM...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > Ok then, I'll update all cmakelist files. > > 2012/2/13 Weddington, Eric <Eri...@at...> > >> >> >> > -----Original Message----- >> > From: Borja Ferrer [mailto:bor...@gm...] >> > Sent: Saturday, February 11, 2012 2:19 PM >> > To: Weddington, Eric >> > Cc: Sherard Dames; avr...@li... >> > Subject: Re: [avr-llvm-devel] Current Status? >> > >> > Not yet but, I've just finished implementing basic support for >> branching and >> > selects. So, before commiting I'm going to update my code to compile >> with >> > latest llvm's trunk and then i will finally upload the code. Btw, is >> anybody >> > here that is going to compile the code in windows? If yes, I will >> update the >> > cmakelist files. >> >> I'm definitely interested in having avr-llvm run on windows. >> > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > > ------------------------------ > > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > > End of avr-llvm-devel Digest, Vol 14, Issue 2 > ********************************************* |
|
From: Borja F. <bor...@gm...> - 2012-02-13 18:03:20
|
Ok then, I'll update all cmakelist files. 2012/2/13 Weddington, Eric <Eri...@at...> > > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Saturday, February 11, 2012 2:19 PM > > To: Weddington, Eric > > Cc: Sherard Dames; avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > Not yet but, I've just finished implementing basic support for > branching and > > selects. So, before commiting I'm going to update my code to compile > with > > latest llvm's trunk and then i will finally upload the code. Btw, is > anybody > > here that is going to compile the code in windows? If yes, I will > update the > > cmakelist files. > > I'm definitely interested in having avr-llvm run on windows. > |
|
From: Weddington, E. <Eri...@at...> - 2012-02-13 17:40:21
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Saturday, February 11, 2012 2:19 PM > To: Weddington, Eric > Cc: Sherard Dames; avr...@li... > Subject: Re: [avr-llvm-devel] Current Status? > > Not yet but, I've just finished implementing basic support for branching and > selects. So, before commiting I'm going to update my code to compile with > latest llvm's trunk and then i will finally upload the code. Btw, is anybody > here that is going to compile the code in windows? If yes, I will update the > cmakelist files. I'm definitely interested in having avr-llvm run on windows. |
|
From: Borja F. <bor...@gm...> - 2012-02-11 21:18:46
|
Not yet but, I've just finished implementing basic support for branching and selects. So, before commiting I'm going to update my code to compile with latest llvm's trunk and then i will finally upload the code. Btw, is anybody here that is going to compile the code in windows? If yes, I will update the cmakelist files. 2012/2/3 Weddington, Eric <Eri...@at...> > Hi Borja, > > Do you have any of your work committed yet? There are other people > interested in helping, but we need to have the latest in the repo... > > Eric > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Friday, February 03, 2012 9:10 AM > > To: Weddington, Eric > > Cc: Sherard Dames; avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > Ahh ok, I will take a look then. > > > > Update: I've already implemented conditional branches for if() > conditions > > (BR_CC node). I still need to work on overriding some virtual > functions in > > some interfaces to improve the generated code. Then I will move to > SETCC and > > SELECT nodes which are used in things like: a = (b > c) and a = (b > > c) ? 1 : > > 2 respectively. > > I'm happy because we can now compile loops :) > > > > > > 2012/1/31 Weddington, Eric <Eri...@at...> > > > > > > Hi Borja, > > > > Thanks for the ping. > > > > Unfortunately the best place to see how address spaces work is > still the > > GCC source code, and documentation :-( > > > > Eric > > > > > > > -----Original Message----- > > > From: Borja Ferrer [mailto:bor...@gm...] > > > > > Sent: Tuesday, January 31, 2012 7:08 AM > > > To: Weddington, Eric > > > Cc: Sherard Dames; avr...@li... > > > Subject: Re: [avr-llvm-devel] Current Status? > > > > > > Update: I've already started working on conditional branches > and > > compares. > > > Eric ping? > > > > > > > > > 2012/1/20 Borja Ferrer <bor...@gm...> > > > > > > > > > Ahh ok thanks for the info Eric, about the work on > doubles, what > > sort of > > > support is it? shouldn't that go into write the math functions > in the > > C > > > library? or do you mean removing the constraint of making > double a > > float? > > > Is there a place on how the multiple address space > feature will > > work, we > > > should implement this aswell in an early stage so it's > important that > > we see > > > how it works to be compatible with what gcc does. > > > > > > > > > 2012/1/16 Weddington, Eric <Eri...@at...> > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Borja Ferrer > [mailto:bor...@gm...] > > > > > > > Sent: Friday, January 13, 2012 9:19 AM > > > > To: Weddington, Eric > > > > Cc: Sherard Dames; > > avr...@li... > > > > Subject: Re: [avr-llvm-devel] Current Status? > > > > > > > > > > > Eric one more thing, you mentioned that some > work has > > been done > > > lately > > > in > > > > gcc's backend, can you tell me what are the > main > > features added > > > and if > > > > there are any code quality improvements. > > > > > > > > > Umpf. There's been so much happening, I'm not > sure if I > > can > > > remember it > > > all > > > > > > - Improvements in the AVR backend, especially a > number > > of missed > > > optimization bugs fixed > > > > > > - The beginning of a Multiple Address Spaces > feature > > > > > > - The beginning of 24-bit types, mainly used for > > Multiple Address > > > Spaces > > > (i.e. large code space, or large data space) > > > > > > - Some work done on 64-bit double types > > > > > > And other fixed bugs. > > > > > > Eric > > > > > > > > > > > > > > > > > |
|
From: Weddington, E. <Eri...@at...> - 2012-02-03 19:02:00
|
Hi Borja, Do you have any of your work committed yet? There are other people interested in helping, but we need to have the latest in the repo... Eric > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Friday, February 03, 2012 9:10 AM > To: Weddington, Eric > Cc: Sherard Dames; avr...@li... > Subject: Re: [avr-llvm-devel] Current Status? > > Ahh ok, I will take a look then. > > Update: I've already implemented conditional branches for if() conditions > (BR_CC node). I still need to work on overriding some virtual functions in > some interfaces to improve the generated code. Then I will move to SETCC and > SELECT nodes which are used in things like: a = (b > c) and a = (b > c) ? 1 : > 2 respectively. > I'm happy because we can now compile loops :) > > > 2012/1/31 Weddington, Eric <Eri...@at...> > > > Hi Borja, > > Thanks for the ping. > > Unfortunately the best place to see how address spaces work is still the > GCC source code, and documentation :-( > > Eric > > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > > Sent: Tuesday, January 31, 2012 7:08 AM > > To: Weddington, Eric > > Cc: Sherard Dames; avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > Update: I've already started working on conditional branches and > compares. > > Eric ping? > > > > > > 2012/1/20 Borja Ferrer <bor...@gm...> > > > > > > Ahh ok thanks for the info Eric, about the work on doubles, what > sort of > > support is it? shouldn't that go into write the math functions in the > C > > library? or do you mean removing the constraint of making double a > float? > > Is there a place on how the multiple address space feature will > work, we > > should implement this aswell in an early stage so it's important that > we see > > how it works to be compatible with what gcc does. > > > > > > 2012/1/16 Weddington, Eric <Eri...@at...> > > > > > > > > > > > > > -----Original Message----- > > > From: Borja Ferrer [mailto:bor...@gm...] > > > > > Sent: Friday, January 13, 2012 9:19 AM > > > To: Weddington, Eric > > > Cc: Sherard Dames; > avr...@li... > > > Subject: Re: [avr-llvm-devel] Current Status? > > > > > > > > Eric one more thing, you mentioned that some work has > been done > > lately > > in > > > gcc's backend, can you tell me what are the main > features added > > and if > > > there are any code quality improvements. > > > > > > Umpf. There's been so much happening, I'm not sure if I > can > > remember it > > all > > > > - Improvements in the AVR backend, especially a number > of missed > > optimization bugs fixed > > > > - The beginning of a Multiple Address Spaces feature > > > > - The beginning of 24-bit types, mainly used for > Multiple Address > > Spaces > > (i.e. large code space, or large data space) > > > > - Some work done on 64-bit double types > > > > And other fixed bugs. > > > > Eric > > > > > > > > > |
14 messages has been excluded from this view by a project administrator.
