avr-llvm-devel — Developers mailing list.

[avr-llvm-devel] Current Status?

[Sherard D. <sc...@gm...>]

Hello everyone,

I'm curious as to the current status of this project. From the looks of
the SVN (and the mailing list) it would appear that the project is
fairly inactive. Is it simply that work is going on behind closed doors?
Or perhaps, is it a dead project?

Re: [avr-llvm-devel] Just getting started, but eager to help (subscribed to the list this time...)

[Borja F. <bor...@gm...>]

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?

Re: [avr-llvm-devel] Just getting started, but eager to help (subscribed to the list this time...)

[Borja F. <bor...@gm...>]

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
> >
> >
>

Re: [avr-llvm-devel] Just getting started, but eager to help (subscribed to the list this time...)

[Anton S. <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
>
>

Re: [avr-llvm-devel] Just getting started, but eager to help (subscribed to the list this time...)

[Borja F. <bor...@gm...>]

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
>
>

Re: [avr-llvm-devel] Just getting started, but eager to help (subscribed to the list this time...)

[Anton S. <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

[avr-llvm-devel] Just getting started, but eager to help (subscribed to the list this time...)

[Borja F. <bor...@gm...>]

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.

Re: [avr-llvm-devel] Just getting started, but eager to help (subscribed to the list this time...)

[Anton S. <an...@so...>]

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
>

Re: [avr-llvm-devel] Just getting started, but eager to help (subscribed to the list this time...)

[John M. <ato...@gm...>]

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

[avr-llvm-devel] Just getting started, but eager to help (subscribed to the list this time...)

[Anton S. <an...@so...>]

    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

[avr-llvm-devel] [PATCH] avr-mingw

[John M. <ato...@gm...>]

There is an extra semicolon which needs to be removed in order for LLVM to
compile using cmake/mingw.
For some reason VS doesn't seem to care or use the file.




Index: lib/Support/Windows/explicit_symbols.inc
===================================================================
--- lib/Support/Windows/explicit_symbols.inc    (revision 132739)
+++ lib/Support/Windows/explicit_symbols.inc    (working copy)
@@ -2,7 +2,7 @@

 #ifdef HAVE__ALLOCA
   EXPLICIT_SYMBOL(_alloca)
-  EXPLICIT_SYMBOL2(alloca, _alloca);
+  EXPLICIT_SYMBOL2(alloca, _alloca)
 #endif
 #ifdef HAVE___ALLOCA
   EXPLICIT_SYMBOL(__alloca)

Re: [avr-llvm-devel] Status update

[Borja F. <bor...@gm...>]

Ok John thanks for looking into it.
I'm still waiting a reply from the llvmdev list about reserving the Y reg
only if accessing the stack, i bumped the issue again to see if somebody
replies. Always reserving the Y reg would very bad for memory operations.

2011/5/25 John Myers <ato...@gm...>

>
>
> On Wed, May 18, 2011 at 2:59 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> PS: John, with clang do you get doubles or long long variables aligned to
>> an 8 byte boundary? I've set their alignments to 1 byte in a constructor
>> (cant remember now the name, but it's in the clang patch files in svn) but
>> they get aligned too much wasting memory. Any ideas there?
>>
> I've never checked the correctness of what the AVR target info produces.
> It's basically a patchwork of other targets like PIC16 and MSP430. There
> isn't much clang documentation for creating a port (at least compared to
> LLVM). I also think clang is X86 centric and has some hard coded assumptions
> of the Target. There are more src files that will need to be modified in
> clang but I believe Target.cpp is the minimum that allows it to be compiled.
> I'll try to find some time to look into it.
>

Re: [avr-llvm-devel] Status update

[John M. <ato...@gm...>]

On Wed, May 18, 2011 at 2:59 PM, Borja Ferrer <bor...@gm...> wrote:

> PS: John, with clang do you get doubles or long long variables aligned to
> an 8 byte boundary? I've set their alignments to 1 byte in a constructor
> (cant remember now the name, but it's in the clang patch files in svn) but
> they get aligned too much wasting memory. Any ideas there?
>
I've never checked the correctness of what the AVR target info produces.
It's basically a patchwork of other targets like PIC16 and MSP430. There
isn't much clang documentation for creating a port (at least compared to
LLVM). I also think clang is X86 centric and has some hard coded assumptions
of the Target. There are more src files that will need to be modified in
clang but I believe Target.cpp is the minimum that allows it to be compiled.
I'll try to find some time to look into it.

Re: [avr-llvm-devel] Status update

[Kevin S. <sch...@kw...>]

Hi folks,

LLVM has support for multiple calling conventions.  In principle someone
could eventually define additional calling conventions to match IAR, gcc
(if that is not the default), or others.

But the two important ones (quoting from the assembly reference) are -
> "ccc" - The C calling convention:
>     This calling convention (the default if no other calling
>     convention is specified) matches the target C calling conventions.
>     This calling convention supports varargs function calls and
>     tolerates some mismatch in the declared prototype and implemented
>     declaration of the function (as does normal C).
> "fastcc" - The fast calling convention:
>     This calling convention attempts to make calls as fast as
>     possible (e.g. by passing things in registers). This calling
>     convention allows the target to use whatever tricks it wants
>     to produce fast code for the target, without having to conform
>     to an externally specified ABI (Application Binary Interface).

Optimization promotes calls to fastcc where possible (generally, if the
function has fixed arguments and is not externally visible). I think in the
(not very) long term the normal use case for AVR would be to have libraries
of LLVM bitcode, rather than object code, and to do link-time whole-program
optimization. Then nearly all calls could be promoted to fastcc, and the
performance of the external calling convention is moot. The fastcc is not
externally visible, so it can be changed over time.

Regards,

-- 
Kevin Schoedel <sch...@kw...> VA3TCS

Re: [avr-llvm-devel] Status update

[Borja F. <bor...@gm...>]

2011/5/20 Weddington, Eric <Eri...@at...>

>
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Thursday, May 19, 2011 3:54 PM
> > To: Weddington, Eric
> > Cc: avr...@li...
> > Subject: Re: [avr-llvm-devel] Status update
> >
> > Hello Eric,
> >
> > It could be possible to implement both ABIs, but right now i'm unsure
> > about how much work that would take and its difficulty. I personally
> > haven't really thought about a new ABI standard since this is something
> > that needs a deep thought and some analysis, indeed some opinions from
> > atmel would be very helpful.
>
> And I'm happy to help out in this area. Agreed, that it will take quite a
> bit of thinking *and* tinkering.
>

Ok then, I guess the best thing to do would be sticking to the gcc ABI until
we get a functional compiler, and then patch it with the new ABI to support
both. However, we could open a new discussion about the new ABI in another
thread during the meantime since this is something that will take some time
to arrive to some consensus and it won't get forgotten.


>
> > I faced these issues while taking a look at
> > how gcc and iar manipulated frames and the stack during the past days,
> and
> > there is where i noticed the huge diference in performance and code size.
> > I really havent taken a look at the IAR ABI standard,
>
> And something to keep in mind is that IAR uses *2* stacks, one for local
> variables and one for function return addresses to quickly pop out of a
> function.
>

Very interesting, I didnt know about this, i guess i'll have to take a look
at the IAR specs to see what it does. Is it even possible to beat IAR's ABI
since you have a better understanding of it?



>
>
> > but i've been
> > comparing code produced (mainly stressing register allocation with math
> > calculations with double precision types) by IAR and llvm and the global
> > difference in code size is only related to the ABI. What do i mean? well,
> > that if we ignore prologue, epilogue and stack manipulation stuff which
> is
> > pure ABI specific, llvm produces shorter code and requires less frame
> > memory, otherwise they perform quite equally on average because of the
> > overhead the gcc ABI has.
>
> Well this is *very* good news then! This means that it is theoretically
> possible to do even better than IAR, if only we design an appropriate ABI. I
> do feel that an alternative, better ABI can be developed. It's just a matter
> of some effort and time.
>

For what i've tested so far which is very "movw" and "call" intensive since
all double operations are function calls, when we get down to lots of arith
operations and stuff like that we'll have to get our hands dirty to combine
operations like IAR does, this is where IAR outperforms gcc. For now im not
focusing at all in optimizations since i want to be able to have a
functional compiler first, but the code produced is quite decent, so when
optimizations get introduced the code quality upgrade should be huge.



>
>
> > My biggest concern here supposing the ABI is changed in the future is the
> > custom assembly written by users, that would mean a huge change for them
> > since they would get forced to rewrite their code and i'm uncertain about
> > their reactions.
>
> I'm a little less concerned, and that's mainly to do with having been in
> this area for several years.
>
> Yes, any ABI change could induce a cost to the end user. However:
>
> - Any cost to the end user would have to be offset by the benefits
> involved. If we can show that avr-llvm can produce smaller code than the
> best commercial AVR compiler on the market, then the benefits far outweigh
> the costs.
>
> - The actual costs would be minimal. Most users write their code in C, or
> even C++. There are very few actual projects out there that include some
> form of assembly. Of those that do, most would use some form of inline
> assembly. There are less users that even have assembly-only functions within
> a larger C project where they have to adjust their prologues and epilogues
> due to an ABI change. And even then, there are usually a very small finite
> number of assembly functions. Even rarer is the true all assembly-only
> application. So, I think, in reality the impact of changing the ABI on user
> applications is extremely small and therefore not as relevant. The biggest
> impact would be on avr-libc.
>

I absolutely agree with you on that. Btw, big words there mentioning beating
the best comercial compiler on the market xD During the years i've been
coding I've never cared about backwards compatibility, when i received the
question about breaking some library interface or binary format my reply was
always go on for it. But this is the first time I think im caring because we
have to first adapt to the users, not the other way round as it always
happened to me.



> > The libc transition would be easier to do since many
> > assembly functions use registers defined in macros instead of using their
> > real names, so that would make things simpler.
>
> Avr-libc would have to be audited to make sure that truly is the case. But
> it's just "work". Not that hard, but a little time-consuming. But I think
> very doable.
>
> > But again, would you then
> > have two different libc's or you would deprecate the one using the old
> > abi? it's not that obvious.
>
> Well, ideally, it might be best to make sure that we could compile avr-libc
> with either ABI while we do a transition. But I think we're putting the cart
> before the horse. I'm willing to look into what that will take with avr-libc
> once we have a working avr-llvm with promise of supplanting avr-gcc with
> better code generation.
>
> Indeed, no need to advance on these things until we get working compiler.



>
> > In relation to the development, right now I'm stuck reserving the Y reg
> > when stack frames are needed so it doesnt get used by anything else. To
> > know if all regs get spilled so stack memory is allocated thus needing Y
> > to access stack memory you need to run the reg allocator but that will
> use
> > the Y reg for other purposes if it's available, so it's like needing to
> > know the future to resolve something in the present. LLVM handles stack
> > stuff in a later stage, after register allocation is done, and there is
> > where you know if you really need to reserve Y to access the stack or you
> > can use it for other things.
>
> It sounds like you've got a handle on what needs to be done. Is there a way
> to run the register allocator more than once? Run it with Y available to see
> if the result works, if not, then reserve Y and run the allocator again
> without Y available?
>
> That's what i've thought as well, i'm going to ask the the llvm dev list to
see if it's possible to do it. 2 weeks ago approx the llvm devs released a
new reg alloc that is the one on by default that reduces frame size by using
more register swapping, i've seen some improvements in little tests i run,
so at least it's good to know that they're very active in improving codegen
quality.


> HTH,
> Eric Weddington
>

Re: [avr-llvm-devel] Status update

[Weddington, E. <Eri...@at...>]

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Thursday, May 19, 2011 3:54 PM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Status update
> 
> Hello Eric,
> 
> It could be possible to implement both ABIs, but right now i'm unsure
> about how much work that would take and its difficulty. I personally
> haven't really thought about a new ABI standard since this is something
> that needs a deep thought and some analysis, indeed some opinions from
> atmel would be very helpful. 

And I'm happy to help out in this area. Agreed, that it will take quite a bit of thinking *and* tinkering.

> I faced these issues while taking a look at
> how gcc and iar manipulated frames and the stack during the past days, and
> there is where i noticed the huge diference in performance and code size.
> I really havent taken a look at the IAR ABI standard, 

And something to keep in mind is that IAR uses *2* stacks, one for local variables and one for function return addresses to quickly pop out of a function.


> but i've been
> comparing code produced (mainly stressing register allocation with math
> calculations with double precision types) by IAR and llvm and the global
> difference in code size is only related to the ABI. What do i mean? well,
> that if we ignore prologue, epilogue and stack manipulation stuff which is
> pure ABI specific, llvm produces shorter code and requires less frame
> memory, otherwise they perform quite equally on average because of the
> overhead the gcc ABI has.

Well this is *very* good news then! This means that it is theoretically possible to do even better than IAR, if only we design an appropriate ABI. I do feel that an alternative, better ABI can be developed. It's just a matter of some effort and time.

 
> My biggest concern here supposing the ABI is changed in the future is the
> custom assembly written by users, that would mean a huge change for them
> since they would get forced to rewrite their code and i'm uncertain about
> their reactions. 

I'm a little less concerned, and that's mainly to do with having been in this area for several years.

Yes, any ABI change could induce a cost to the end user. However:

- Any cost to the end user would have to be offset by the benefits involved. If we can show that avr-llvm can produce smaller code than the best commercial AVR compiler on the market, then the benefits far outweigh the costs.

- The actual costs would be minimal. Most users write their code in C, or even C++. There are very few actual projects out there that include some form of assembly. Of those that do, most would use some form of inline assembly. There are less users that even have assembly-only functions within a larger C project where they have to adjust their prologues and epilogues due to an ABI change. And even then, there are usually a very small finite number of assembly functions. Even rarer is the true all assembly-only application. So, I think, in reality the impact of changing the ABI on user applications is extremely small and therefore not as relevant. The biggest impact would be on avr-libc.


> The libc transition would be easier to do since many
> assembly functions use registers defined in macros instead of using their
> real names, so that would make things simpler. 

Avr-libc would have to be audited to make sure that truly is the case. But it's just "work". Not that hard, but a little time-consuming. But I think very doable.

> But again, would you then
> have two different libc's or you would deprecate the one using the old
> abi? it's not that obvious.

Well, ideally, it might be best to make sure that we could compile avr-libc with either ABI while we do a transition. But I think we're putting the cart before the horse. I'm willing to look into what that will take with avr-libc once we have a working avr-llvm with promise of supplanting avr-gcc with better code generation.


> In relation to the development, right now I'm stuck reserving the Y reg
> when stack frames are needed so it doesnt get used by anything else. To
> know if all regs get spilled so stack memory is allocated thus needing Y
> to access stack memory you need to run the reg allocator but that will use
> the Y reg for other purposes if it's available, so it's like needing to
> know the future to resolve something in the present. LLVM handles stack
> stuff in a later stage, after register allocation is done, and there is
> where you know if you really need to reserve Y to access the stack or you
> can use it for other things.

It sounds like you've got a handle on what needs to be done. Is there a way to run the register allocator more than once? Run it with Y available to see if the result works, if not, then reserve Y and run the allocator again without Y available?

HTH,
Eric Weddington

Re: [avr-llvm-devel] Status update

[Borja F. <bor...@gm...>]

Hello Eric,

It could be possible to implement both ABIs, but right now i'm unsure about
how much work that would take and its difficulty. I personally haven't
really thought about a new ABI standard since this is something that needs a
deep thought and some analysis, indeed some opinions from atmel would be
very helpful. I faced these issues while taking a look at how gcc and iar
manipulated frames and the stack during the past days, and there is where i
noticed the huge diference in performance and code size. I really havent
taken a look at the IAR ABI standard, but i've been comparing code produced
(mainly stressing register allocation with math calculations with double
precision types) by IAR and llvm and the global difference in code size is
only related to the ABI. What do i mean? well, that if we ignore prologue,
epilogue and stack manipulation stuff which is pure ABI specific, llvm
produces shorter code and requires less frame memory, otherwise they perform
quite equally on average because of the overhead the gcc ABI has.

My biggest concern here supposing the ABI is changed in the future is the
custom assembly written by users, that would mean a huge change for them
since they would get forced to rewrite their code and i'm uncertain about
their reactions. The libc transition would be easier to do since many
assembly functions use registers defined in macros instead of using their
real names, so that would make things simpler. But again, would you then
have two different libc's or you would deprecate the one using the old abi?
it's not that obvious.

In relation to the development, right now I'm stuck reserving the Y reg when
stack frames are needed so it doesnt get used by anything else. To know if
all regs get spilled so stack memory is allocated thus needing Y to access
stack memory you need to run the reg allocator but that will use the Y reg
for other purposes if it's available, so it's like needing to know the
future to resolve something in the present. LLVM handles stack stuff in a
later stage, after register allocation is done, and there is where you know
if you really need to reserve Y to access the stack or you can use it for
other things.

Re: [avr-llvm-devel] Status update

[Weddington, E. <Eri...@at...>]

Hi Borja,

I totally agree that the ABI for AVR GCC basically sucks. However, we have compatibility issues if we hope to win over users. Basically this means that we should endeavor to be able to use avr-libc with avr-llvm, and this means that we have to keep to the same ABI as avr-gcc. Avr-libc is written in mostly optimized assembly, so changing the ABI means an awful lot of work in avr-libc.

However, we should also keep in mind 2 things:

- There has been some talk, here and there, of *eventually* changing the ABI of AVR GCC to something more rational and efficient. The argument stops because of how much work there is to do it and generally not enough resources. But everyone usually agrees that it needs to be done. So I can easily see that the ABI will eventually change in the future.

- To that end, if there is a way for you to do *both* ABIs, and be able to switch back and forth with a switch, then I would highly recommend that you do that. I know it means extra work. But this would be a great selling point. Have it default to the AVR GCC ABI, but if you can come up with a more efficient ABI (and I can do some internal research as to what would be ideal and report back on that) *and* implement it, then it could be shown to users how much better this ABI is *and* that avr-llvm already implements it. Then it would be easier to get the needed work done on avr-libc to switch it over.

HTH,
Eric Weddington

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Wednesday, May 18, 2011 3:00 PM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Status update
> 
> Hello, while working on the stack and frame stuff a question came to my
> mind. Are we going to use exactly the same ABI as gcc? Basically i'm
> asking this because each time we need to inc/dec the SP we have to use
> many instructions, for example in a function prologue gcc uses 8. From
> what i've seen IAR stores SP in Y so manipulating it doesn't need in/out
> insts, reading SREG or disabling interrupts which is much shorter. When
> passing parameters through the stack to functions it gets longer because
> SP has to be decremented and restored using in/outs on each call. Gah
> Eric, why is SP was mapped in the IO space? xD
> 
> Anyway, if somebody has a better idea let me know otherwise I'll implement
> what gcc does.
> 
> PS: John, with clang do you get doubles or long long variables aligned to
> an 8 byte boundary? I've set their alignments to 1 byte in a constructor
> (cant remember now the name, but it's in the clang patch files in svn) but
> they get aligned too much wasting memory. Any ideas there?
> 

Re: [avr-llvm-devel] Status update

[Borja F. <bor...@gm...>]

Hello, while working on the stack and frame stuff a question came to my
mind. Are we going to use exactly the same ABI as gcc? Basically i'm asking
this because each time we need to inc/dec the SP we have to use many
instructions, for example in a function prologue gcc uses 8. From what i've
seen IAR stores SP in Y so manipulating it doesn't need in/out insts,
reading SREG or disabling interrupts which is much shorter. When passing
parameters through the stack to functions it gets longer because SP has to
be decremented and restored using in/outs on each call. Gah Eric, why is SP
was mapped in the IO space? xD

Anyway, if somebody has a better idea let me know otherwise I'll implement
what gcc does.

PS: John, with clang do you get doubles or long long variables aligned to an
8 byte boundary? I've set their alignments to 1 byte in a constructor (cant
remember now the name, but it's in the clang patch files in svn) but they
get aligned too much wasting memory. Any ideas there?

Re: [avr-llvm-devel] Status update

[Borja F. <bor...@gm...>]

Already working in stack frames.

Re: [avr-llvm-devel] Status update

[Borja F. <bor...@gm...>]

Ok right now at 4:30am I've just finished all this stuff. So finally we can
say that global loading and storing is fully functional.

2011/4/21 Borja Ferrer <bor...@gm...>

> I'm 50% done with the global lds/sts stuff. Currently, these instructions
> get selected for non array variables for char and int types. For the array
> case, something like char g_var[11] = 0 is generating:
> ldi r24, 0
> ldi r30, g_var // should have the lo8, hi8 macros, i know xD
> ldi r31, g_var
> std Z+11, r24
>
> obviously this add has to be performed at compile time to this:
> ldi r24, 0
> sts g_var+11, r24
>
> also I'm looking into how how generate the hi8/lo8 macros that are needed
> to get the lo and hi part of the addresses. So at this stage I'm working out
> these cases to get the optimal code sequence, i'll post an update when i
> advance further with this.
>
>

Re: [avr-llvm-devel] Status update

[Borja F. <bor...@gm...>]

I'm 50% done with the global lds/sts stuff. Currently, these instructions
get selected for non array variables for char and int types. For the array
case, something like char g_var[11] = 0 is generating:
ldi r24, 0
ldi r30, g_var // should have the lo8, hi8 macros, i know xD
ldi r31, g_var
std Z+11, r24

obviously this add has to be performed at compile time to this:
ldi r24, 0
sts g_var+11, r24

also I'm looking into how how generate the hi8/lo8 macros that are needed to
get the lo and hi part of the addresses. So at this stage I'm working out
these cases to get the optimal code sequence, i'll post an update when i
advance further with this.

Re: [avr-llvm-devel] Status update

[Borja F. <bor...@gm...>]

John it seems you did a diff patch for SelectionDAG (which is empty) instead
of SelectionDAGBuilder.cpp, the patch for the other file is correct, thanks.
Also, could you please make a branch for the 2.9 release, there is some code
there that will be useful in the future.

Re: [avr-llvm-devel] Status update

[Borja F. <bor...@gm...>]

John can you make a diff patch of the following changes and include them in
the patch file in svn? This patch is necesarry in LLVM to be able to know
the size of function arguments when calling external symbols, and is
required for my latests changes.

TargetCallingConv.h
Add
    static const uint64_t SplitPiece     = 0x3FULL << 11;
    static const uint64_t SplitPieceOffs = 11;
after
    static const uint64_t SplitOffs      = 10;

Add
    unsigned getSplitPiece() const {
      return (unsigned)((Flags & SplitPiece) >> SplitPieceOffs);
    }
    void setSplitPiece(unsigned S) {
      Flags = (Flags & ~SplitPiece) | (uint64_t(S) << SplitPieceOffs);
    }
After
    void setByValSize(unsigned S) {
      Flags = (Flags & ~ByValSize) | (uint64_t(S) << ByValSizeOffs);
    }
(Introduce a newline after the setByValSize closing brace)

SelectionDAGBuilder.cpp
Add
MyFlags.Flags.setSplitPiece(j);
After
        ISD::OutputArg MyFlags(Flags, Parts[j].getValueType(),
                               i < NumFixedArgs);
(around line 6115)

Add
MyFlags.Flags.setSplitPiece(i);
After
ISD::InputArg MyFlags(Flags, RegisterVT, isArgValueUsed);
(around line 6310)

Re: [avr-llvm-devel] Status update

[Weddington, E. <Eri...@at...>]

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Monday, April 11, 2011 10:03 AM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Status update
> 
> I would like to finish up the global load/store stuff before committing
> the new code. Also during the next week i'm going to be very very busy so
> i can't precisely say when it will happen, unless threre's some sort of
> big reason that requires to commit the code :) So i would say at the end
> of next week.

Sounds good. No, there's no pressing reason, just excited to see it. :-)

> As a side note, i've finished up working with predrecement loads/stores,
> so now it's time for lds/sts for real.

:-D