From: Anton S. <an...@so...> - 2011-06-10 04:42:06
|
Hello Borja, John, Eric and all, I would love to see great Clang/LLVM support for the AVR architecture. And so I'm hoping to help out here. To get a feel for Clang and LLVM, as well as the avr-llvm back end I have been trying to get the full tool chain to compile. I ran into a couple of problems (patches included) that I'm not sure are actually problems, or just my missunderstandings, or perhaps known issues that are being ignored because of the forthcoming rewrite. In any case, working out these few blockers has help me understand the code base (that and the excellent documentation online on how to write an LLVM backend). Eric, I think we talked a couple of years ago at ESC about alternatives to the PROGMEM solution in avr-gcc and avr-libc. I am excited to see that progress with named address spaces has been made in both GCC and Clang/LLVM and it seems like an excellent tool to simplify not just flash, but also external memory and EEPROM access. The two issues I ran into are that TargetMachine::getFrameInfo() has been renamed to TargetMachine::getFrameLowering() and that TargetLowering::ReplaceNodeResults was not implemented in AVRTargetLowering. I don't expect that the patches below will be very useful by them selves. I'm more curious if I'm at least on the right page. It seems like until the new backend is available it may be more worth my time looking into helping out with the Clang cross compilation work. In particular the TargetInfo being baked into libs/Basic/Targets.cpp seems like an area for cleanup. I think that there was a thread about this on the clang list recently. I'll do some more reading there. Thanks, Anton >From 17ac3236221dd46556c240fe61491614b6c7b536 Mon Sep 17 00:00:00 2001 From: Anton Staaf <an...@so...> Date: Wed, 1 Jun 2011 08:47:48 -0700 Subject: [PATCH 1/2] TargetMachine: Track name change: GetFrameInfo -> GetFrameLowering Signed-off-by: Anton Staaf <an...@so...> --- llvm/trunk/AVR/AVRTargetMachine.cpp | 2 +- llvm/trunk/AVR/AVRTargetMachine.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/llvm/trunk/AVR/AVRTargetMachine.cpp b/llvm/trunk/AVR/AVRTargetMachine.cpp index 19772c7..7d8ca24 100644 --- a/llvm/trunk/AVR/AVRTargetMachine.cpp +++ b/llvm/trunk/AVR/AVRTargetMachine.cpp @@ -65,7 +65,7 @@ const AVRSubtarget *AVRTargetMachine::getSubtargetImpl() const return &Subtarget; } -const TargetFrameLowering *AVRTargetMachine::getFrameInfo() const +const TargetFrameLowering *AVRTargetMachine::getFrameLowering() const { return &FrameLowering; } diff --git a/llvm/trunk/AVR/AVRTargetMachine.h b/llvm/trunk/AVR/AVRTargetMachine.h index 2d81ccb..3078fb2 100644 --- a/llvm/trunk/AVR/AVRTargetMachine.h +++ b/llvm/trunk/AVR/AVRTargetMachine.h @@ -39,7 +39,7 @@ public: // TargetMachine const TargetData *getTargetData() const; const AVRRegisterInfo *getRegisterInfo() const; const AVRSubtarget *getSubtargetImpl() const; - const TargetFrameLowering *getFrameInfo() const; + const TargetFrameLowering *getFrameLowering() const; const AVRSelectionDAGInfo *getSelectionDAGInfo() const; bool addInstSelector(PassManagerBase &PM, CodeGenOpt::Level OptLevel); bool addPreEmitPass(PassManagerBase &PM, CodeGenOpt::Level OptLevel); -- 1.7.1 >From 19f96f2c4f64279e4bbbfa9d9de9f80f4fa15a2e Mon Sep 17 00:00:00 2001 From: Anton Staaf <an...@so...> Date: Wed, 1 Jun 2011 08:48:39 -0700 Subject: [PATCH 2/2] Add AVRTargetLowering::ReplaceNodeResults method. Signed-off-by: Anton Staaf <an...@so...> --- llvm/trunk/AVR/AVRISelLowering.cpp | 28 ++++++++++++++++++++++++---- llvm/trunk/AVR/AVRISelLowering.h | 4 +++- 2 files changed, 27 insertions(+), 5 deletions(-) diff --git a/llvm/trunk/AVR/AVRISelLowering.cpp b/llvm/trunk/AVR/AVRISelLowering.cpp index 5f18763..1698b24 100644 --- a/llvm/trunk/AVR/AVRISelLowering.cpp +++ b/llvm/trunk/AVR/AVRISelLowering.cpp @@ -255,7 +255,7 @@ SDValue AVRTargetLowering::LowerOperation(SDValue Op, SelectionDAG &DAG) const case ISD::ROTR: case ISD::SRL: case ISD::SHL: return LowerShifts(Op, DAG); - case ISD::GlobalAddress: return LowerGlobalAddress(Op, DAG); + case ISD::GlobalAddress: return LowerGlobalAddress(Op.getNode(), DAG); case ISD::ADD: return ExpandADDSUB(Op.getNode(), DAG); case ISD::ADDE: return ExpandADDSUB(Op.getNode(), DAG); case ISD::OR: return ExpandOR(Op.getNode(), DAG); @@ -266,6 +266,25 @@ SDValue AVRTargetLowering::LowerOperation(SDValue Op, SelectionDAG &DAG) const } } +/// ReplaceNodeResults - Replace the results of node with an illegal result +/// type with new values built out of custom code. +void AVRTargetLowering::ReplaceNodeResults(SDNode *N, + SmallVectorImpl<SDValue>&Results, + SelectionDAG &DAG) const +{ + SDValue Res; + switch (N->getOpcode()) { + default: + llvm_unreachable("Don't know how to custom expand this!"); + break; + case ISD::GlobalAddress: + Res = LowerGlobalAddress(N, DAG); + break; + } + if (Res.getNode()) + Results.push_back(Res); +} + //===----------------------------------------------------------------------===// // Calling Convention Implementation //===----------------------------------------------------------------------===// @@ -761,11 +780,12 @@ SDValue AVRTargetLowering::LowerShifts(SDValue Op, SelectionDAG &DAG) const } SDValue -AVRTargetLowering::LowerGlobalAddress(SDValue Op, SelectionDAG &DAG) const +AVRTargetLowering::LowerGlobalAddress(SDNode *N, SelectionDAG &DAG) const { - DebugLoc dl = Op.getDebugLoc(); + SDValue Op; + DebugLoc dl = N->getDebugLoc(); assert(0 && "custom GLOBADDRESD" ); - const GlobalValue *GV = cast<GlobalAddressSDNode>(Op)->getGlobal(); + const GlobalValue *GV = cast<GlobalAddressSDNode>(N)->getGlobal(); Op = DAG.getTargetGlobalAddress(GV, dl, getPointerTy()); return DAG.getNode(AVRISD::Wrapper, dl, getPointerTy(), Op); diff --git a/llvm/trunk/AVR/AVRISelLowering.h b/llvm/trunk/AVR/AVRISelLowering.h index 0535171..a46318c 100644 --- a/llvm/trunk/AVR/AVRISelLowering.h +++ b/llvm/trunk/AVR/AVRISelLowering.h @@ -50,6 +50,8 @@ public : // TargetLowering unsigned getFunctionAlignment(const Function *) const; const char *getTargetNodeName(unsigned Opcode) const; SDValue LowerOperation(SDValue Op, SelectionDAG &DAG) const; + void ReplaceNodeResults(SDNode *N, SmallVectorImpl<SDValue> &Results, + SelectionDAG &DAG) const; private: void AnalyzeArguments(const Function *F, CCState &CCInfo) const; void AnalyzeReturn(CCState &CCInfo, @@ -91,7 +93,7 @@ private: SmallVectorImpl<SDValue> &InVals) const; // Custom lowering functions SDValue LowerShifts(SDValue Op, SelectionDAG &DAG) const; - SDValue LowerGlobalAddress(SDValue Op, SelectionDAG &DAG) const; + SDValue LowerGlobalAddress(SDNode *N, SelectionDAG &DAG) const; private: const TargetData *TD; }; -- 1.7.1 |
From: Borja F. <bor...@gm...> - 2011-06-17 15:45:26
|
Welcome Anton! Your patches are on the right track, however please dont spend much time taking a look and working with the current backend in SVN because it's going to be completely replaced. I would recommend taking a read through previous threads in the mailing list to take a grasp of what is the current status and what are the problems we've been having and how some have been resolved, I would say bacl from October-2010 to today. Many interface changes are happening in LLVM so I doubt the backend compiles at all for the latest release. As a short summary, I have a more developed backend out of SVN with a completely different design (you can read about it in older threads) that has to be uploaded. Currently, I'm working on everything related to frame stuff which is a big milestone. I have to ask something to the llvm devs because I'm stuck on something before continuing the work. You mentioned about helping on the Clang side, that would be awesome because right now nobody is working on that, and indeed, all the address space stuff has to be resolved, so your work there would be really appreciated. PS: since mid may I'm inactive because of my finals until july so i wont be able to resume work until then, but i'll keep reading the mailing list to follow up any discussions. |
From: Anton S. <an...@so...> - 2011-06-23 03:49:02
|
> > Your patches are on the right track, however please dont spend much time > taking a look and working with the current backend in SVN because it's going > to be completely replaced. I would recommend taking a read through previous > threads in the mailing list to take a grasp of what is the current status > and what are the problems we've been having and how some have been resolved, > I would say bacl from October-2010 to today. Many interface changes are > happening in LLVM so I doubt the backend compiles at all for the latest > release. > Yup, that's what I had gathered. I am very much looking forward to the new back-end going up. I'd love to help out with it. As a short summary, I have a more developed backend out of SVN with a > completely different design (you can read about it in older threads) that > has to be uploaded. Currently, I'm working on everything related to frame > stuff which is a big milestone. I have to ask something to the llvm devs > because I'm stuck on something before continuing the work. > Indeed, I was tracking your conversation about function preambles. It seems like while supporting both the IAR and GCC styles would be very useful (perhaps with IAR behind a flag) it would also be considerable work. Have you decided on a stack management style? You mentioned about helping on the Clang side, that would be awesome because > right now nobody is working on that, and indeed, all the address space stuff > has to be resolved, so your work there would be really appreciated. > Good to hear, I've been continuing to experiment there. PS: since mid may I'm inactive because of my finals until july so i wont be > able to resume work until then, but i'll keep reading the mailing list to > follow up any discussions. > Good luck on your finals. Thanks, Anton |
From: Borja F. <bor...@gm...> - 2011-10-12 23:19:26
|
Hello everybody, I'm sorry about the long time without any updates (around june), I've been very busy during these months so I've been unable to do any work. Did anybody advanced on something during this time? If i remember correctly the last thing i was working on were stack frames, so i'll continue the work from there. But first I'll have to update myself to see the changes in llvm's trunk during all this time, and then update my local repo to compile with their latest code, I'm guessing some work there because of their API changes. This will take me some days, and then back to coding. 2011/6/23 Anton Staaf <an...@so...> > Your patches are on the right track, however please dont spend much time >> taking a look and working with the current backend in SVN because it's going >> to be completely replaced. I would recommend taking a read through previous >> threads in the mailing list to take a grasp of what is the current status >> and what are the problems we've been having and how some have been resolved, >> I would say bacl from October-2010 to today. Many interface changes are >> happening in LLVM so I doubt the backend compiles at all for the latest >> release. >> > > Yup, that's what I had gathered. I am very much looking forward to the new > back-end going up. I'd love to help out with it. > > As a short summary, I have a more developed backend out of SVN with a >> completely different design (you can read about it in older threads) that >> has to be uploaded. Currently, I'm working on everything related to frame >> stuff which is a big milestone. I have to ask something to the llvm devs >> because I'm stuck on something before continuing the work. >> > > Indeed, I was tracking your conversation about function preambles. It > seems like while supporting both the IAR and GCC styles would be very useful > (perhaps with IAR behind a flag) it would also be considerable work. Have > you decided on a stack management style? > > You mentioned about helping on the Clang side, that would be awesome >> because right now nobody is working on that, and indeed, all the address >> space stuff has to be resolved, so your work there would be really >> appreciated. >> > > Good to hear, I've been continuing to experiment there. > > PS: since mid may I'm inactive because of my finals until july so i wont be >> able to resume work until then, but i'll keep reading the mailing list to >> follow up any discussions. >> > > Good luck on your finals. > > Thanks, > Anton > > |
From: Anton S. <an...@so...> - 2011-11-21 02:15:19
|
Hi Borja, I haven't done anything much. I have been lurking on the Clang and LLVM lists as well gaining insight and poking at code. It looks like there is a renewed effort in the abstraction of calling convention and architecture independence from developers on both sides of the bitcode divide. Which would be great for backends like this one. But I've spent most of my open source programming time on U-Boot actually. I am very interested in your new AVR backend and would love to play with it and help out. I look forward to seeing it. :) Thanks, Anton On Wed, Oct 12, 2011 at 4:19 PM, Borja Ferrer <bor...@gm...> wrote: > Hello everybody, I'm sorry about the long time without any updates (around > june), I've been very busy during these months so I've been unable to do any > work. Did anybody advanced on something during this time? > If i remember correctly the last thing i was working on were stack frames, > so i'll continue the work from there. But first I'll have to update myself > to see the changes in llvm's trunk during all this time, and then update my > local repo to compile with their latest code, I'm guessing some work there > because of their API changes. This will take me some days, and then back to > coding. > > 2011/6/23 Anton Staaf <an...@so...> >>> >>> Your patches are on the right track, however please dont spend much time >>> taking a look and working with the current backend in SVN because it's going >>> to be completely replaced. I would recommend taking a read through previous >>> threads in the mailing list to take a grasp of what is the current status >>> and what are the problems we've been having and how some have been resolved, >>> I would say bacl from October-2010 to today. Many interface changes are >>> happening in LLVM so I doubt the backend compiles at all for the latest >>> release. >> >> Yup, that's what I had gathered. I am very much looking forward to the >> new back-end going up. I'd love to help out with it. >>> >>> As a short summary, I have a more developed backend out of SVN with a >>> completely different design (you can read about it in older threads) that >>> has to be uploaded. Currently, I'm working on everything related to frame >>> stuff which is a big milestone. I have to ask something to the llvm devs >>> because I'm stuck on something before continuing the work. >> >> Indeed, I was tracking your conversation about function preambles. It >> seems like while supporting both the IAR and GCC styles would be very useful >> (perhaps with IAR behind a flag) it would also be considerable work. Have >> you decided on a stack management style? >>> >>> You mentioned about helping on the Clang side, that would be awesome >>> because right now nobody is working on that, and indeed, all the address >>> space stuff has to be resolved, so your work there would be really >>> appreciated. >> >> Good to hear, I've been continuing to experiment there. >>> >>> PS: since mid may I'm inactive because of my finals until july so i wont >>> be able to resume work until then, but i'll keep reading the mailing list to >>> follow up any discussions. >> >> Good luck on your finals. >> Thanks, >> Anton > > |
From: Borja F. <bor...@gm...> - 2011-11-30 20:54:46
|
Ahh i see, that's fine. I've just commited a patch file that adds some custom code to the register allocator that reserves REG_Y on the fly when it's used as a frame pointer. This has given me a bit of a headache because with the current API it's not possible to do it, so I had to add a small hack to make it work, now it's behaving the same way as GCC. Next I have to work at passing local stack variables as parameters to functions and allocating stack space, I think that should be it related to stack and frame work (I'm leaving varargs for later xD). 2011/11/21 Anton Staaf <an...@so...> > Hi Borja, I haven't done anything much. I have been lurking on the > Clang and LLVM lists as well gaining insight and poking at code. It > looks like there is a renewed effort in the abstraction of calling > convention and architecture independence from developers on both sides > of the bitcode divide. Which would be great for backends like this > one. > > But I've spent most of my open source programming time on U-Boot > actually. I am very interested in your new AVR backend and would love > to play with it and help out. I look forward to seeing it. :) > > Thanks, > Anton > > On Wed, Oct 12, 2011 at 4:19 PM, Borja Ferrer <bor...@gm...> > wrote: > > Hello everybody, I'm sorry about the long time without any updates > (around > > june), I've been very busy during these months so I've been unable to do > any > > work. Did anybody advanced on something during this time? > > If i remember correctly the last thing i was working on were stack > frames, > > so i'll continue the work from there. But first I'll have to update > myself > > to see the changes in llvm's trunk during all this time, and then update > my > > local repo to compile with their latest code, I'm guessing some work > there > > because of their API changes. This will take me some days, and then back > to > > coding. > > > > 2011/6/23 Anton Staaf <an...@so...> > >>> > >>> Your patches are on the right track, however please dont spend much > time > >>> taking a look and working with the current backend in SVN because it's > going > >>> to be completely replaced. I would recommend taking a read through > previous > >>> threads in the mailing list to take a grasp of what is the current > status > >>> and what are the problems we've been having and how some have been > resolved, > >>> I would say bacl from October-2010 to today. Many interface changes are > >>> happening in LLVM so I doubt the backend compiles at all for the latest > >>> release. > >> > >> Yup, that's what I had gathered. I am very much looking forward to the > >> new back-end going up. I'd love to help out with it. > >>> > >>> As a short summary, I have a more developed backend out of SVN with a > >>> completely different design (you can read about it in older threads) > that > >>> has to be uploaded. Currently, I'm working on everything related to > frame > >>> stuff which is a big milestone. I have to ask something to the llvm > devs > >>> because I'm stuck on something before continuing the work. > >> > >> Indeed, I was tracking your conversation about function preambles. It > >> seems like while supporting both the IAR and GCC styles would be very > useful > >> (perhaps with IAR behind a flag) it would also be considerable work. > Have > >> you decided on a stack management style? > >>> > >>> You mentioned about helping on the Clang side, that would be awesome > >>> because right now nobody is working on that, and indeed, all the > address > >>> space stuff has to be resolved, so your work there would be really > >>> appreciated. > >> > >> Good to hear, I've been continuing to experiment there. > >>> > >>> PS: since mid may I'm inactive because of my finals until july so i > wont > >>> be able to resume work until then, but i'll keep reading the mailing > list to > >>> follow up any discussions. > >> > >> Good luck on your finals. > >> Thanks, > >> Anton > > > > > |
From: Borja F. <bor...@gm...> - 2011-12-13 19:16:35
|
Short status update: Last weekend I finished working on stack frames and passing function arguments through the stack. This includes prologue and epilogue code, saving all callee registers, being able to allocate local variables (and taking their address) and allocating/restoring stack space before/after a function call that needs arguments passed through the stack. Next thing I'm going to work on is going to be unconditional and conditional branching. That will help us testing larger test cases, because for now all i can test is linear code. I'm going to be quite busy these weeks, but i'll try to push some work on it. Another thing, is anybody willing to write some testcases so we can do regression testing? |
From: John M. <ato...@gm...> - 2011-06-10 18:41:50
|
Hi Anton, On Thu, Jun 9, 2011 at 9:41 PM, Anton Staaf <an...@so...> wrote: > Hello Borja, John, Eric and all, > I would love to see great Clang/LLVM support for the AVR architecture. And > so I'm hoping to help out here. > Do you have a sourceforge account? > The two issues I ran into are that TargetMachine::getFrameInfo() has > been renamed to TargetMachine::getFrameLowering() and that > TargetLowering::ReplaceNodeResults was not implemented in AVRTargetLowering. > I don't expect that the patches below will be very useful by them selves. > I'm more curious if I'm at least on the right page. > > Which svn version are you using? Some of the changes in your patches are already committed (rev 110). You're on the right page but wrong sentence :) There is a lot of refactoring of clang/LLVM like this which sometimes makes it hard to keep up with ToT of clang/LLVM. For me at least it's been a good way of becoming a little more familiar with the internals of LLVM. > It seems like until the new backend is available it may be more worth > my time looking into helping out with the Clang cross compilation work. In > particular the TargetInfo being baked into libs/Basic/Targets.cpp seems like > an area for cleanup. I think that there was a thread about this on the > clang list recently. I'll do some more reading there. > > Thanks, > Anton > Yeah, I agree. I've been spending my time trying to get familiar with clang and how the toolchain/driver code works. --John |
From: Anton S. <an...@so...> - 2011-06-11 05:25:55
|
John, On Fri, Jun 10, 2011 at 11:41 AM, John Myers <ato...@gm...>wrote: > Hi Anton, > > > On Thu, Jun 9, 2011 at 9:41 PM, Anton Staaf <an...@so...>wrote: > >> Hello Borja, John, Eric and all, >> > I would love to see great Clang/LLVM support for the AVR architecture. And >> so I'm hoping to help out here. >> > Do you have a sourceforge account? > I do, I'm not sure I understand the connection though. :) The two issues I ran into are that TargetMachine::getFrameInfo() has >> been renamed to TargetMachine::getFrameLowering() and that >> TargetLowering::ReplaceNodeResults was not implemented in AVRTargetLowering. >> I don't expect that the patches below will be very useful by them selves. >> I'm more curious if I'm at least on the right page. >> >> Which svn version are you using? Some of the changes in your patches are > already committed (rev 110). You're on the right page but wrong sentence :) > There is a lot of refactoring of clang/LLVM like this which sometimes makes > it hard to keep up with ToT of clang/LLVM. For me at least it's been a good > way of becoming a little more familiar with the internals of LLVM. > I based my patch against revision 121. I'll take a look and see what happened, but at least I know I wasn't in the weeds. > >> It seems like until the new backend is available it may be more worth >> my time looking into helping out with the Clang cross compilation work. In >> particular the TargetInfo being baked into libs/Basic/Targets.cpp seems like >> an area for cleanup. I think that there was a thread about this on the >> clang list recently. I'll do some more reading there. >> >> Thanks, >> Anton >> > > Yeah, I agree. I've been spending my time trying to get familiar with clang > and how the toolchain/driver code works. > > > --John > |