avr-llvm-devel — Developers mailing list.

Re: [avr-llvm-devel] Status update

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

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.
As a side note, i've finished up working with predrecement loads/stores, so
now it's time for lds/sts for real.

2011/4/10 Weddington, Eric <Eri...@at...>

>
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Sunday, April 10, 2011 9:48 AM
> > To: Weddington, Eric
> > Cc: avr...@li...
> > Subject: Re: [avr-llvm-devel] Status update
> >
> > Small update:
> > Today I've finished introducing support for post-increment load and
> > stores. Pre-decrement should be nearly copy paste with some small
> changes.
> > After this is done, i'll take a look at lds/sts as mentioned in a
> previous
> > email so we can load/store globals (only data memory at the moment).
>
> Thanks for doing this! What are your plans for committing your new work?
>

Re: [avr-llvm-devel] Status update

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

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Sunday, April 10, 2011 9:48 AM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Status update
> 
> Small update:
> Today I've finished introducing support for post-increment load and
> stores. Pre-decrement should be nearly copy paste with some small changes.
> After this is done, i'll take a look at lds/sts as mentioned in a previous
> email so we can load/store globals (only data memory at the moment).

Thanks for doing this! What are your plans for committing your new work?

Re: [avr-llvm-devel] Status update

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

Small update:
Today I've finished introducing support for post-increment load and stores.
Pre-decrement should be nearly copy paste with some small changes. After
this is done, i'll take a look at lds/sts as mentioned in a previous email
so we can load/store globals (only data memory at the moment).

John i will try renaming the clang folder since i'm working in linux.

Re: [avr-llvm-devel] Status update

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

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Tuesday, April 05, 2011 5:45 PM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Status update
> 
> Hello Eric, I phrased that in a wrong way sorry :) Basically when i wrote
> that movws were going to be emitted always i meant that they were going to
> be emitted directly by the compiler and not manually inserted as it's
> currently happening. The current implementation searches for 8 bit moves
> and tries to transform 2 moves in a row to a single movw, but it's missing
> many cases so that's why they dont get always emitted. With the new
> implementation, since the compiler is emitting real 16bit moves we will
> have a movw when it's needed so there's no danger of getting movws lost.

Ah, ok. That makes more sense. Thanks for the clarification.

<snip>
 
> OFFTOPIC: During the past weeks i've been implementing a 4 stage pipelined
> MIPS core in Verilog for an FPGA for a master class project, and now i
> really have a good feeling of the beauty of what is inside the RISC cpus.
> It's nice to have different point of views: the programmer, the compiler,
> the CPU core hardware...

Very cool! :-)

Eric
 

Re: [avr-llvm-devel] Status update

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

On Tue, Apr 5, 2011 at 2:31 PM, Borja Ferrer <bor...@gm...> wrote:

> PS: John do you get clang rebuilt each time you recompile LLVM, if that's
> the case do you know a way to stop this because linking it takes like 40secs
> here. Im using ccache as mentioned in some doc file.
>


No, if I remember correctly, mostly only the clang source files that have
changed get compiled. I think certain LLVM library's cause parts of clang to
be rebuild though. I remember working on some parts of LLVM would seem to
cause the clang compilations to take a long time compared to when I would
modify other files in LLVM. On Linux using *configure *I used to rename *
tools/clang* which keeps the LLVM build system from trying to compile clang
also. With CMake+VS you can disable compilation of each project separately.

Re: [avr-llvm-devel] Status update

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

Hello Eric, I phrased that in a wrong way sorry :) Basically when i wrote
that movws were going to be emitted always i meant that they were going to
be emitted directly by the compiler and not manually inserted as it's
currently happening. The current implementation searches for 8 bit moves and
tries to transform 2 moves in a row to a single movw, but it's missing many
cases so that's why they dont get always emitted. With the new
implementation, since the compiler is emitting real 16bit moves we will have
a movw when it's needed so there's no danger of getting movws lost.

About what you mentioned about other devices, indeed this is something that
has to be done. I already kept this in mind, thinking about the tiny devices
that lack mul, movw, and other instructions support, with 8 bit ptrs, and
the largests that have 24?bit ptrs. LLVM has a very nice interface to handle
this sort of stuff, so in theory it shouldnt be hard to implement, but
really tedious. Basically, first you define a device model say the
ATMEGA644PA and in there you can list its supported features, in x86 these
features would be SSE1, SSE2, AVX, etc.. in our case we would have MUL,
MOVW, ELPM and friends, support etc. Then when emitting the code we check if
for example movw is supported for the current device, if it's not supported
then LLVM has to take another path and emit a different instruction, or if
for example the device doesnt have a builtin multiplier then either expand
the mult instr into a chain of adds or make a libcall.
I'm really interested in your help when we start supporting other devices to
get things right and support every single device in the market. We'll need a
good classification of the devices to list these features i mentioned so we
can add them for every supported device. For the moment im focusing in the
atmega644, which has a lots of features in its CPU core, and then for
smaller devices we'll have to add restrictions as explained above to avoid
illegal instructions getting emitted, and for larger devices ... well i cant
talk about those for now because i've never worked with them.

OFFTOPIC: During the past weeks i've been implementing a 4 stage pipelined
MIPS core in Verilog for an FPGA for a master class project, and now i
really have a good feeling of the beauty of what is inside the RISC cpus.
It's nice to have different point of views: the programmer, the compiler,
the CPU core hardware...

Re: [avr-llvm-devel] Status update

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

Wow! Thanks for the update! :-)

I like what I'm hearing so far. The cons don't sound all that bad, considering the pros that you mentioned. It sounds to me that you're on the right track, but I'll be interested in what others have to say, too.

My only caution comes from what you said about using movw always: There are avr chip variants that don't have a movw instruction. For that matter there are different instruction set variants that are dependent on the avr device type. AVR GCC sort-of handles this by organizing the list of chips into arbitrary "architectures", which are then associated with memory ranges and loosely based instruction sets. However, there always seems to be some exceptions to the rule.

So my only advice to you is to keep this in mind and that we'll need to have some sort of mechanism to tie the avr device type with enabling/disabling specific instructions. I don't really care if we use a similar mechanism as AVR GCC with these arbitrary architectures. However, I would be fine too if we dropped the "architectures", because these are arbitrary and there are exceptions and sometimes they're more of a maintenance headache than it's worth. (As a side note, this is one area where I hope to help out in, though I still have quite a learning curve.)

With this, also keep in mind that there is a relatively new AVR sub-family, based on the newly released ATtiny10 (all variants: ATtiny10/4/5/9/20/40). This is a weird family:
- The register file is cut in half. It only has R16-R31, however R0-R15 still exist, they just map to the upper half of the register file.
- Reduced instruction set. There are a number of disabled instructions (have to see datasheets for full list).
- Really small amounts of flash (code), and even smaller amounts of RAM (data).
Yet, with all of these limitations, there is still a desire to have a C compiler for these devices. The latest "AVR Toolchain" release from Atmel has support for these devices.

Thanks again, Borja, for your work on this! I'm really excited to see your work committed! :-)

Eric Weddington

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Tuesday, April 05, 2011 3:31 PM
> To: avr...@li...
> Subject: [avr-llvm-devel] Status update
> 
> Hello, it's been a little while since last time we got an update. Although
> I haven't commited any code during the last 3 months, I want to say that
> doesn't mean the project is dead or something similar, it's just the
> opposite that's why i want to explain what is the current status, in fact
> i havent stopped working on this at all.
> 
> From Jan to approximately March I've been investigating different ways to
> handle the insane reg constraints to pair adjacent regs to store 16bit and
> wider data with the PBQP allocator and other ideas i had, I think i had
> like 4 branches to see which one was the best. From here I want to give a
> big thank to Lang Hames, the author of this allocator for all the help he
> gave me and for his interest. But solving this using this approach was
> getting pretty hard, tracking which virtual reg had the low and hi part of
> a 16bit value is simply impossible in LLVM with the current interfaces in
> order to build the constraint matrix for the PBPQ allocator, in addition,
> there were other underlying problems when working with only 8bit types as
> a legal sizes, like 16 bit pointers.
> 
> So around mid March I started a new backend from scratch with a new idea
> which has simplified everything in a huge manner. Like everything in this
> life, all things have pros and cons so we have to get a balance. The
> biggest pro of this approach is it's simplicity, the cons is that we'll
> have to work a bit harder to get some nice optimizations in. But these
> cons aren't too bad at all, because most of them would have to be handled
> in all aproaches so after all, we will have to get our hands dirty to get
> really nice code.
> The basic idea is to make 16bit data legal, that means working with pseudo
> register pairs and psuedo 16 bit instructions that need to get expanded
> into 8 bit instructions in a later stage. When we get a movw or adiw/sbiw
> we leave them alone because they're legal instructions but when we get say
> a 16bit and instr we have to expand it to two and instructions. As i said,
> when we move further we can start thinking in introducing optimizations
> over pseudo intrs which is something that gcc doesn't do very well, and
> after all we want to beat it.
> 
> So the current status is:
> - Added support for all arithmetic and binary instructions for all data
> types, except mul. Including, INC/DEC, COM/NEG and SWAP.
> - Convert all (add x, imm) into sub(x, -imm) since we dont have an add
> with imm instruction. This saves doing ldi+add into a subi.
> - Handle adiw/sbiw instructions when it's beneficial.
> - Allocate everything in register pairs, as it should be, and emit movw
> always, no need for more heuristics.
> - Implemented calling conventions, including argument passing, return
> values, and function calls, including externals symbols which isn't
> handled in the current backend in SVN.
> - Pointers are now 16bits as it should be, and not 8bits as a hack.
> - Added support for ICALL.
> - BIG ONE: Added support for data memory operatons, this includes: ld,
> ldd, st and std. This adds support for the reg+imm addressing mode when
> imm<64.
> - Print for ld, ldd, st and std when emmiting asm code the X, Y, Z names.
> 
> I think this is it for the moment, probably i've left something out, but
> those are the basic points. I'm currently working in adding support for
> lds and sts, so we can load/store global symbols. And after that is
> implemented we'll be able to implement stack frames, which is an important
> milestone.
> I'll commit the new code in a few days, i want to get something done
> before. Let me know your thoughts. For me the most important part is to
> remark that we're moving further.
> 
> PS: John do you get clang rebuilt each time you recompile LLVM, if that's
> the case do you know a way to stop this because linking it takes like
> 40secs here. Im using ccache as mentioned in some doc file.

[avr-llvm-devel] Status update

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

Hello, it's been a little while since last time we got an update. Although I
haven't commited any code during the last 3 months, I want to say that
doesn't mean the project is dead or something similar, it's just the
opposite that's why i want to explain what is the current status, in fact i
havent stopped working on this at all.

>From Jan to approximately March I've been investigating different ways to
handle the insane reg constraints to pair adjacent regs to store 16bit and
wider data with the PBQP allocator and other ideas i had, I think i had like
4 branches to see which one was the best. From here I want to give a big
thank to Lang Hames, the author of this allocator for all the help he gave
me and for his interest. But solving this using this approach was getting
pretty hard, tracking which virtual reg had the low and hi part of a 16bit
value is simply impossible in LLVM with the current interfaces in order to
build the constraint matrix for the PBPQ allocator, in addition, there were
other underlying problems when working with only 8bit types as a legal
sizes, like 16 bit pointers.

So around mid March I started a new backend from scratch with a new idea
which has simplified everything in a huge manner. Like everything in this
life, all things have pros and cons so we have to get a balance. The biggest
pro of this approach is it's simplicity, the cons is that we'll have to work
a bit harder to get some nice optimizations in. But these cons aren't too
bad at all, because most of them would have to be handled in all aproaches
so after all, we will have to get our hands dirty to get really nice code.
The basic idea is to make 16bit data legal, that means working with pseudo
register pairs and psuedo 16 bit instructions that need to get expanded into
8 bit instructions in a later stage. When we get a movw or adiw/sbiw we
leave them alone because they're legal instructions but when we get say a
16bit and instr we have to expand it to two and instructions. As i said,
when we move further we can start thinking in introducing optimizations over
pseudo intrs which is something that gcc doesn't do very well, and after all
we want to beat it.

So the current status is:
- Added support for all arithmetic and binary instructions for all data
types, except mul. Including, INC/DEC, COM/NEG and SWAP.
- Convert all (add x, imm) into sub(x, -imm) since we dont have an add with
imm instruction. This saves doing ldi+add into a subi.
- Handle adiw/sbiw instructions when it's beneficial.
- Allocate everything in register pairs, as it should be, and emit movw
always, no need for more heuristics.
- Implemented calling conventions, including argument passing, return
values, and function calls, including externals symbols which isn't handled
in the current backend in SVN.
- Pointers are now 16bits as it should be, and not 8bits as a hack.
- Added support for ICALL.
- BIG ONE: Added support for data memory operatons, this includes: ld, ldd,
st and std. This adds support for the reg+imm addressing mode when imm<64.
- Print for ld, ldd, st and std when emmiting asm code the X, Y, Z names.

I think this is it for the moment, probably i've left something out, but
those are the basic points. I'm currently working in adding support for lds
and sts, so we can load/store global symbols. And after that is implemented
we'll be able to implement stack frames, which is an important milestone.
I'll commit the new code in a few days, i want to get something done before.
Let me know your thoughts. For me the most important part is to remark that
we're moving further.

PS: John do you get clang rebuilt each time you recompile LLVM, if that's
the case do you know a way to stop this because linking it takes like 40secs
here. Im using ccache as mentioned in some doc file.

Re: [avr-llvm-devel] Building on windows / mingw

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

> -----Original Message-----
> From: Patrick Rosendahl [mailto:Pat...@gm...]
> Sent: Friday, April 01, 2011 11:36 AM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] Building on windows / mingw
> 
> There was some work on the register-allocation, so that 16bit moves can be
> generated ( = adjacent pairs of 8bit registers).
> What is the status on that? Can I help somewhere?
> 
> Once someone decides how to deal with 16bit 'registers' in llvm, I think
> implementing the instruction set is straight forward.

Yeah, I'm hoping that we can get going on this soon.

 
> Building: the patch-files are a little outdated, but you can fix the
> failed lines easily by hand.
> 

Thanks for the note! :-)

Eric

Re: [avr-llvm-devel] Building on windows / mingw

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

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...]
> Sent: Friday, April 01, 2011 9:46 AM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Building on windows / mingw
> 
> 
> There is information in docs/gettingstarted.html and /trunk/README.
> I've only built avr-llvm with Visual Studio on windows. But I believe you
> need to use cmake
> 
> for mingw also. Changing the '-G' option for cmake should be all that is
> needed.

Thanks John! I'll give it a shot.

Eric

Re: [avr-llvm-devel] Building on windows / mingw

[Patrick R. <Pat...@gm...>]

There was some work on the register-allocation, so that 16bit moves can be generated ( = adjacent pairs of 8bit registers).
What is the status on that? Can I help somewhere?

Once someone decides how to deal with 16bit 'registers' in llvm, I think implementing the instruction set is straight forward.


Building: the patch-files are a little outdated, but you can fix the failed lines easily by hand.

/Patrick

On 31.03.2011, at 19:02, Weddington, Eric wrote:

> Hi All,
> 
> It's been a while since we've had some discussion about this project. I've been meaning to get around to building avr-llvm on windows / mingw. But first, I'd like to see the general directions on how to build avr-llvm. I know some things have changed since I first looked at those directions. Could someone point me to a document that provides the current build directions?
> 
> Thanks,
> Eric Weddington

Re: [avr-llvm-devel] Building on windows / mingw

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

On Thu, Mar 31, 2011 at 10:02 AM, Weddington, Eric <
Eri...@at...> wrote:

> Hi All,
>
> It's been a while since we've had some discussion about this project. I've
> been meaning to get around to building avr-llvm on windows / mingw. But
> first, I'd like to see the general directions on how to build avr-llvm. I
> know some things have changed since I first looked at those directions.
> Could someone point me to a document that provides the current build
> directions?
>
> Thanks,
> Eric Weddington
>

There is information in *docs/gettingstarted.html* and */trunk/README*.
I've only built avr-llvm with Visual Studio on windows. But I believe you
need to use cmake
for mingw also. Changing the '-G' option for cmake should be all that is
needed.

--John

[avr-llvm-devel] Building on windows / mingw

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

Hi All,

It's been a while since we've had some discussion about this project. I've been meaning to get around to building avr-llvm on windows / mingw. But first, I'd like to see the general directions on how to build avr-llvm. I know some things have changed since I first looked at those directions. Could someone point me to a document that provides the current build directions?

Thanks,
Eric Weddington

Re: [avr-llvm-devel] Important stuff

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

I'm currently working with the PBQP allocator to add the pairing
constraints. It can manage ordered pairs, for it, we need to tell if a
virtual register is mapped to the lo or the hi part of the data to produce
the correct code. John, now that atleast the pairing stuff is a bit clearer
for the moment, we have to look at inserting 16 bit instructions like movw
and adiw/sbiw. You can look at the pass i wrote to replace moves with movws,
ideally i would like LLVM to do it automatically but i dont know if this is
possible, so i guess this is what we need to investigate before proceeding
into other things.

Re: [avr-llvm-devel] Important stuff

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

On Sun, Dec 5, 2010 at 10:40 AM, Borja Ferrer <bor...@gm...> wrote:

> I'm currently discussing this issue in the llvmdev mailing list because it
> seems there's no easy way to work with register pairs. You can check it in
> the thread with title "Register Pairing". Basically this is the code im
> testing, it shows how some regs arent paired correctly missing movw
> insertion opportunities:
> <snip>
> ; here we have the case i was explaining, pairs dont match because they're
> the other way round, function result is in r25:r24
> ; but it's storing the hi part in r20 instead of r21, so we cant insert a
> movw
>    mov    r20, r25
>    mov    r21, r24 <--- should be mov r21, r25; mov r20, r24 to be able to
> insert a movw
> <snip>
> John if you have any suggestions they're welcome. I've also asked how to
> combine two 8 bit instructions into a 16 bit one, mainly for movw and
> adiw/sbiw. I wrote a function pass that searches 2 moves in a row and
> combines them into a movw, but if other instructions get in between the
> moves like it happens in the previous example (note those ands and xors)
> then they get missed. GCC has an easy way of handling the register pairing
> issue, Lang in the mailing list suggested using his register allocator which
> is able to work with constraints like the ones we have, look in the src for
> PBQP.
>

It's starting to sound like, from reading the other thread, that we will
need to modify the LLVM code generator and/or tablegen  to get the registers
to be assigned in the correct order. So the PBQP solver can create pairs but
I'm wondering if it will it also be able to assign them in the correct
order? The PBQP sounds really interesting. I've tried reading up on the
concept a few times before but still haven't looked at the source code yet.

Re: [avr-llvm-devel] Important stuff

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

I'm currently discussing this issue in the llvmdev mailing list because it
seems there's no easy way to work with register pairs. You can check it in
the thread with title "Register Pairing". Basically this is the code im
testing, it shows how some regs arent paired correctly missing movw
insertion opportunities:

typedef short t;
extern t mcos(t a);
extern t mdiv(t a, t b);
t foo(t a, t b)
{
   short p1 = mcos(b);
   short p2 = mcos(a);
   return mdiv(p1&p2, p1^p2);
}

This C code produces (for purists, ignore the fact that it's using scratch
regs between calls, this is unimplemented):
; a<- r25:r24   b<--r23:r22
   mov    r18, r24
   mov    r19, r25 <-- can be combined into a movw r19:r18, r25:r24
   mov    r25, r23
   mov    r24, r22 <-- can be combined into a movw r25:r24, r23:r22
   call    mcos
; here we have the case i was explaining, pairs dont match because they're
the other way round, function result is in r25:r24
; but it's storing the hi part in r20 instead of r21, so we cant insert a
movw
   mov    r20, r25
   mov    r21, r24 <--- should be mov r21, r25; mov r20, r24 to be able to
insert a movw
   mov    r25, r19
   mov    r24, r18 <-- can be combined into a movw r25:r24, r19:r18
   call    mcos
; same problem as above, again it's moving the hi part in r25 into r18
instead of r19 so we've lost another movw here
   mov    r18, r25 <-- should be mov r19, r25
   and    r18, r20
   mov    r19, r24 <-- should be mov r18, r24
   and    r19, r21
   mov    r23, r25 <-- this *
   eor    r23, r20
   mov    r22, r24 <--  * and this could be combined into movw r23:r22,
r25:r24
   eor    r22, r21
   mov    r25, r18
   mov    r24, r19 <-- because the result returned by the second call to
mcos is stored in r18:r19 (other way round)
                         ; we've lost another movw
   call    mdiv
   ret

John if you have any suggestions they're welcome. I've also asked how to
combine two 8 bit instructions into a 16 bit one, mainly for movw and
adiw/sbiw. I wrote a function pass that searches 2 moves in a row and
combines them into a movw, but if other instructions get in between the
moves like it happens in the previous example (note those ands and xors)
then they get missed. GCC has an easy way of handling the register pairing
issue, Lang in the mailing list suggested using his register allocator which
is able to work with constraints like the ones we have, look in the src for
PBQP.

Re: [avr-llvm-devel] Important stuff

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

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Friday, November 26, 2010 4:28 AM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] Important stuff
> 
> During the past few days i've been investigating how to do this, i'm
> playing with the register file description and custom lowering. What i
> thought is to always use register pairs, split them to perform the 8 bit
> operation and join them again for the next operation, of course this is
> for data wider than 8bits.
> Right now i'm getting promising results, but still needs improvement, llvm
> is using a new register when splitting the pair instead of using the same
> subreg. I'll continue investigating, and post any results, we really need
> to get this clear before advancing into more complex operations like
> memory stuff and branching.

Thanks, Borja, for looking into this. Agreed that this is an important step to get right before doing more complex operations. Your help in this area is very much appreciated. :-)

Eric Weddington

Re: [avr-llvm-devel] Important stuff

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

During the past few days i've been investigating how to do this, i'm playing
with the register file description and custom lowering. What i thought is to
always use register pairs, split them to perform the 8 bit operation and
join them again for the next operation, of course this is for data wider
than 8bits.
Right now i'm getting promising results, but still needs improvement, llvm
is using a new register when splitting the pair instead of using the same
subreg. I'll continue investigating, and post any results, we really need to
get this clear before advancing into more complex operations like memory
stuff and branching.

2010/11/19 Borja Ferrer <bor...@gm...>

> We need to figure out some important things that need to be introduced in
> the compiler before we advance with bigger things. The things i'm talking
> about are:
>
> 1) aligning data wider than 1 byte in even registers to favour movws and
> argument passing into functions.
>  int16 a = b; // a = r21:r20, b = r13:r12
>  movw r20, r12 <--- good reg allocation
>
>  int16 a = b; // a = r20:r21, b = r12:r13
>  mov r21, r13
>  mov r20, r12 <--- bad reg allocation
>
> 2) THE BIG ONE: working with register pairs. there are some instructions
> like sbiw/adiw, movw, ld/st that only work with register pairs. we need to
> figure out how to introduce them.
> For example, I wrote a pass that converts 2 moves in a row into a movw.
> This is very basic, but i find it bad, because if the compiler places an
> instruction between both moves this pass wont be able to replace it with the
> movw. Also i find it very hacky, because the compiler doesnt know that there
> is really a move instruction that work with 16bit data so it doesnt have a
> global view of the costs and probably worsening reg allocation.
>
> If we worked with pseudo regs of 16 bits this should be straight forward,
> but we would face the problem i mentioned some time ago, all data operations
> would need custom lowering, because LLVM isnt able to split a wider reg into
> subregs (say R1312 into R13:R12). An initial guess would be manually
> splitting the reg into its subregs, perform the operation and finally
> recombining the subregs again into the bigger one for next instruction, but
> im not sure yet if this is a good solution.
>
> We really need to think about it because it's a very important design
> decision. This was my first email into llvm's dev mailing list, but i really
> didnt got any real solution.
> If you can think of any other points related to this, add them.
>
>

[avr-llvm-devel] Important stuff

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

We need to figure out some important things that need to be introduced in
the compiler before we advance with bigger things. The things i'm talking
about are:

1) aligning data wider than 1 byte in even registers to favour movws and
argument passing into functions.
 int16 a = b; // a = r21:r20, b = r13:r12
 movw r20, r12 <--- good reg allocation

 int16 a = b; // a = r20:r21, b = r12:r13
 mov r21, r13
 mov r20, r12 <--- bad reg allocation

2) THE BIG ONE: working with register pairs. there are some instructions
like sbiw/adiw, movw, ld/st that only work with register pairs. we need to
figure out how to introduce them.
For example, I wrote a pass that converts 2 moves in a row into a movw. This
is very basic, but i find it bad, because if the compiler places an
instruction between both moves this pass wont be able to replace it with the
movw. Also i find it very hacky, because the compiler doesnt know that there
is really a move instruction that work with 16bit data so it doesnt have a
global view of the costs and probably worsening reg allocation.

If we worked with pseudo regs of 16 bits this should be straight forward,
but we would face the problem i mentioned some time ago, all data operations
would need custom lowering, because LLVM isnt able to split a wider reg into
subregs (say R1312 into R13:R12). An initial guess would be manually
splitting the reg into its subregs, perform the operation and finally
recombining the subregs again into the bigger one for next instruction, but
im not sure yet if this is a good solution.

We really need to think about it because it's a very important design
decision. This was my first email into llvm's dev mailing list, but i really
didnt got any real solution.
If you can think of any other points related to this, add them.

Re: [avr-llvm-devel] About rev 108

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

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Thursday, November 18, 2010 3:23 AM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] About rev 108
> 
> I agree that doing it incrementally simplifies the work instead of doing
> it all once. I'll switch my current setup and use the llvm repository,
> agreed?
> 

Sounds good to me.

Thanks again for all your help! :-)

Re: [avr-llvm-devel] About rev 108

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

I agree that doing it incrementally simplifies the work instead of doing it
all once. I'll switch my current setup and use the llvm repository, agreed?

2010/11/18 Weddington, Eric <Eri...@at...>

>
> I kinda thought that doing it incrementally would keep overall hassles to a
> minimum, plus it keeps us aware of what's happening on the trunk, rather
> than keep working on old stuff. I think that was the rationale, though
> admittedly I think that none of us has really strong opinions about it.
>
> Eric Weddington
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Wednesday, November 17, 2010 4:28 PM
> > To: avr...@li...
> > Subject: Re: [avr-llvm-devel] About rev 108
> >
> > Well, i dont really care either, my current local setup is to only
> support
> > v2.8 and not trunk, this was my though on how it was going to be done. I
> > noticed these changes in llvm's rep but didnt apply them because my idea
> > was to merge them once we switched to 2.9.
> > So if we have to work with trunk as the codebase instead of 2.8 now is
> the
> > moment to decide.
> >
> >
> > 2010/11/17 John Myers <ato...@gm...>
> >
> >
> >
> >
> >       On Wed, Nov 17, 2010 at 3:58 AM, Borja Ferrer
> > <bor...@gm...> wrote:
> >
> >
> >               Hello John i'm not at home now to check this but i've
> noticed
> > your last commit introduces a change that im unsure now if it's
> compatible
> > with our current code base which is v2.8.
> >
> >
> --------------------------------------------------------------
> > ----------------
> >
> >
> >       Yeah, the last few commits have been to synchronize with the LLVM
> > trunk. I guess this is one if the development decisions we should have
> > discussed before continuing. The way we were doing it before was to try
> to
> > keep the avr-llvm trunk up to date with the LLVM trunk.
> >
> >       There are pros and cons for both methods (incremental vs. single
> > shot). The other devs wanted to incrementally keep up with the LLVM
> trunk,
> > but personally I don't have a strong opinion either way.
> >
>
>

Re: [avr-llvm-devel] About rev 108

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

I kinda thought that doing it incrementally would keep overall hassles to a minimum, plus it keeps us aware of what's happening on the trunk, rather than keep working on old stuff. I think that was the rationale, though admittedly I think that none of us has really strong opinions about it.

Eric Weddington

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Wednesday, November 17, 2010 4:28 PM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] About rev 108
> 
> Well, i dont really care either, my current local setup is to only support
> v2.8 and not trunk, this was my though on how it was going to be done. I
> noticed these changes in llvm's rep but didnt apply them because my idea
> was to merge them once we switched to 2.9.
> So if we have to work with trunk as the codebase instead of 2.8 now is the
> moment to decide.
> 
> 
> 2010/11/17 John Myers <ato...@gm...>
> 
> 
> 
> 
> 	On Wed, Nov 17, 2010 at 3:58 AM, Borja Ferrer
> <bor...@gm...> wrote:
> 
> 
> 		Hello John i'm not at home now to check this but i've noticed
> your last commit introduces a change that im unsure now if it's compatible
> with our current code base which is v2.8.
> 
> 		--------------------------------------------------------------
> ----------------
> 
> 
> 	Yeah, the last few commits have been to synchronize with the LLVM
> trunk. I guess this is one if the development decisions we should have
> discussed before continuing. The way we were doing it before was to try to
> keep the avr-llvm trunk up to date with the LLVM trunk.
> 
> 	There are pros and cons for both methods (incremental vs. single
> shot). The other devs wanted to incrementally keep up with the LLVM trunk,
> but personally I don't have a strong opinion either way.
> 

Re: [avr-llvm-devel] About rev 108

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

Well, i dont really care either, my current local setup is to only support
v2.8 and not trunk, this was my though on how it was going to be done. I
noticed these changes in llvm's rep but didnt apply them because my idea was
to merge them once we switched to 2.9.
So if we have to work with trunk as the codebase instead of 2.8 now is the
moment to decide.

2010/11/17 John Myers <ato...@gm...>

>
>
> On Wed, Nov 17, 2010 at 3:58 AM, Borja Ferrer <bor...@gm...>wrote:
>
>> Hello John i'm not at home now to check this but i've noticed your last
>> commit introduces a change that im unsure now if it's compatible with our
>> current code base which is v2.8.
>>
>> ------------------------------------------------------------------------------
>>
> Yeah, the last few commits have been to synchronize with the LLVM trunk. I
> guess this is one if the development decisions we should have discussed
> before continuing. The way we were doing it before was to try to keep the
> avr-llvm trunk up to date with the LLVM trunk.
>
> There are pros and cons for both methods (incremental vs. single shot). The
> other devs wanted to incrementally keep up with the LLVM trunk, but
> personally I don't have a strong opinion either way.
>

Re: [avr-llvm-devel] About rev 108

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

On Wed, Nov 17, 2010 at 3:58 AM, Borja Ferrer <bor...@gm...> wrote:

> Hello John i'm not at home now to check this but i've noticed your last
> commit introduces a change that im unsure now if it's compatible with our
> current code base which is v2.8.
>
> ------------------------------------------------------------------------------
>
Yeah, the last few commits have been to synchronize with the LLVM trunk. I
guess this is one if the development decisions we should have discussed
before continuing. The way we were doing it before was to try to keep the
avr-llvm trunk up to date with the LLVM trunk.

There are pros and cons for both methods (incremental vs. single shot). The
other devs wanted to incrementally keep up with the LLVM trunk, but
personally I don't have a strong opinion either way.

Re: [avr-llvm-devel] Load / Store

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

I've been very busy these days so i haven't got time to discuss this with my
friend, i hope to do it in the next few days.

Also mention that during my nearly inexistent spare time i've been reading
the codegeneration source code line by line to grasp all the low level
details to get a better general view in how to continue developing the
backend. I had some doubts about DAGs that i've resolved by reading the
code. I would like to finish reading it (70% done) before writing more code
in order to do it as better as possible.

2010/11/10 Borja Ferrer <bor...@gm...>

> >>Obviously all the real decisions, especially on what's worth spending
> time on, need to be made by the people actually spending their
> >> time doing the work.
> Yes Kevin, but the more opinions and arguments we get the better we'll be
> able to decide, because this is as a C standard issue that is always hard to
> decide.
>
> >> In all reality, wouldn't avr-llvm have to work with avr-libc as it's
> standard C library?
> Yes, i've never thought of using a different C library or remaking a new
> one, my opinion is that we should stick to it.
>
>
> 2010/11/10 Weddington, Eric <Eri...@at...>
>
>
>>
>> > -----Original Message-----
>> > From: John Myers [mailto:ato...@gm...]
>> > Sent: Tuesday, November 09, 2010 4:47 PM
>> > To: Weddington, Eric
>> > Cc: Borja Ferrer; avr...@li...
>> > Subject: Re: [avr-llvm-devel] Load / Store
>> >
>> >
>> >
>>
>> > I don't believe it does. What part of the standard do you
>> > think it violates? The C language standard doesn't really
>> > deal with multiple address spaces so it can't be an explicit
>> > violation of the standard.
>>
>> There is a draft change to the standard that deals with multiple address
>> spaces. The work that has been done in GCC for multiple address spaces
>> conforms to this draft.
>>
>> > I even see a superscript text note
>> > in the draft of the standard that says: "implementations may
>> > place a const object that is not volatile in a read-only
>> > region of storage".
>>
>> Hmm. Ok, so I'm wrong. :-)
>>
>> Most implementations I've seen have a semantic difference between
>> something that is just *read only* and actually placing it in a different
>> address space.
>>
>> If we don't equate the two it might make implementation easier though.
>>
>
>