From: Stepan D. <stp...@na...> - 2013-06-10 18:03:18
|
Guys, I propose to make your back-end stable and join to LLVM project then. Yes, just add your back-end to LLVM. There are few advantages: 1. You won't synchronize it anymore. If somebody will brake AVR backend, then, according to LLVM policy: it *his* blame, and he will fix it, not you and me. You will get some kind of protection. 2. Being in main llvm repo, AVR backend will attract more developers and testers, more people that may be interested in your code. 3. You lose nothing in that case. Benefits only. 4. You will still code owners, of course. What do you think? -Stepan. |
From: Weddington, E. <Eri...@at...> - 2013-06-10 18:13:57
|
> -----Original Message----- > From: Stepan Dyatkovskiy [mailto:stp...@na...] > Sent: Monday, June 10, 2013 12:03 PM > To: John Myers; Borja Ferrer; avr-llvm > Subject: [avr-llvm-devel] May be join to LLVM? > > Guys, > > I propose to make your back-end stable and join to LLVM project then. > Yes, just add your back-end to LLVM. There are few advantages: > 1. You won't synchronize it anymore. If somebody will brake AVR > backend, > then, according to LLVM policy: it *his* blame, and he will fix it, not > you and me. You will get some kind of protection. > 2. Being in main llvm repo, AVR backend will attract more developers > and > testers, more people that may be interested in your code. > 3. You lose nothing in that case. Benefits only. > 4. You will still code owners, of course. > > What do you think? > Well the thought was crossing my mind this morning... The only reason to have a separate project was to develop the AVR backend sufficiently enough that it worked. The intent, if I recall, was always to merge with LLVM at some point (to be determined). Are we at that point now that it will benefit us to merge with LLVM? Eric |
From: Borja F. <bor...@gm...> - 2013-06-10 19:13:05
|
Adding a backend to LLVM is not an easy thing to do, there was a discussion in the llvm mailing list some time ago about merging experimental backends, and even the devs didnt seem to agree too much. They don't like mantaining backends each time a modification has to be done. I think they proposed to have new backends in some experimental branch and if after some time they got positive feedback they would be finally merged to trunk. The biggest problem I see now is that we would have to merge our out of tree patches, some of them are very hacky and i know they're not going to like them. 2013/6/10 Weddington, Eric <Eri...@at...> > > > -----Original Message----- > > From: Stepan Dyatkovskiy [mailto:stp...@na...] > > Sent: Monday, June 10, 2013 12:03 PM > > To: John Myers; Borja Ferrer; avr-llvm > > Subject: [avr-llvm-devel] May be join to LLVM? > > > > Guys, > > > > I propose to make your back-end stable and join to LLVM project then. > > Yes, just add your back-end to LLVM. There are few advantages: > > 1. You won't synchronize it anymore. If somebody will brake AVR > > backend, > > then, according to LLVM policy: it *his* blame, and he will fix it, not > > you and me. You will get some kind of protection. > > 2. Being in main llvm repo, AVR backend will attract more developers > > and > > testers, more people that may be interested in your code. > > 3. You lose nothing in that case. Benefits only. > > 4. You will still code owners, of course. > > > > What do you think? > > > > Well the thought was crossing my mind this morning... > > The only reason to have a separate project was to develop the AVR backend > sufficiently enough that it worked. The intent, if I recall, was always to > merge with LLVM at some point (to be determined). Are we at that point now > that it will benefit us to merge with LLVM? > > Eric > |
From: <sch...@kw...> - 2013-06-10 19:46:37
|
On Mon, 10 Jun 2013 21:12:58 +0200, Borja Ferrer wrote > Adding a backend to LLVM is not an easy thing to do, there was a discussion > in the llvm mailing list some time ago about merging experimental > backends, and even the devs didnt seem to agree too much. They don't > like mantaining backends each time a modification has to be done. I > think they proposed to have new backends in some experimental branch > and if after some time they got positive feedback they would be > finally merged to trunk. Yes, that thread starts here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051929.html The most recent discussions about adding specific new backends are: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-March/060015.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-March/060508.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061170.html (I think...) -- Kevin Schoedel <sch...@kw...> VA3TCS |
From: Weddington, E. <Eri...@at...> - 2013-06-10 19:21:26
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Monday, June 10, 2013 1:13 PM > To: Weddington, Eric > Cc: Stepan Dyatkovskiy; John Myers; avr-llvm > Subject: Re: [avr-llvm-devel] May be join to LLVM? > > Adding a backend to LLVM is not an easy thing to do, there was a > discussion in the llvm mailing list some time ago about merging > experimental backends, and even the devs didnt seem to agree too much. > They don't like mantaining backends each time a modification has to be > done. I think they proposed to have new backends in some experimental > branch and if after some time they got positive feedback they would be > finally merged to trunk. I just asked on the main llvm-dev mailing list. Let's see what kind of response we'll get. Merging with llvm does mean that the AVR backend will have to be regularly maintained. That's fairly standard even on GCC; no one there will continue to maintain the AVR port. It's up to the port maintainers. > The biggest problem I see now is that we would have to merge our out of > tree patches, some of them are very hacky and i know they're not going > to like them. Then they'll need to be put in a shape that can be accepted. :-) |
From: Borja F. <bor...@gm...> - 2013-06-10 20:31:17
|
2013/6/10 Weddington, Eric <Eri...@at...> > Then they'll need to be put in a shape that can be accepted. :-) > > That's going to be the biggest issue, some of them are very specific and will require changing several LLVM interfaces. |