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

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

Heh i knew this part was going to bring in some debate. Kevin thanks for the
link to the C spec pdf file, i think we should try this approach now that we
have the opportunity of doing things from scratch to improve what GCC
offers. The PROGMEM attribute is a good workaround, but supporting this
natively would bring around more benefits like pushing optimizations further
avoiding many function calls and having some alias ptr analysis. As far as i
know LLVM has address space identifiers in its IR so in theory it's possible
to do it, however i havent looked yet how to implement this in the backend.
Another thing, i havent checked if clang supports named address spaces, i
know gcc does, but at the end we should end up using only clang as the
frontend?

Can somebody clarify me if GCC has support for 24 bit ptrs for largest
devices and 8 bit ptrs for the smallests? i'm only used to 16 bit ptrs so i
dont what gcc does outside this case.
Implementing 24bit ptrs should be possible, same for 8bit.

Deciding what ptr to use is not trivial, i took a fast read to gcc's code
and i think there was a function that decided which reg pair had to be used,
i could be wrong though. I did some tests and for example the Y ptr is
favored against X if there's no frame ptr in the function, so this has to be
taken into account. I need to look how ARM does this, they have 5 or 6
different addressing modes in their .td file. These decisions have to be
taken after knowing what type of operations are done in the ptr itself, so
for example if we have one ptr access that doesnt need doing ptr+<offs> X
can be used otherwise use Z or Y, but as i said this needs doing a previous
analysis, imagine functions with lots of traffic between arrays, there has
to be some logic behind.