llvm dev - Nov 2019 - Built in progmem variables in AVR

Hello.

I was wondering if it is possible to implement placing RO variables within
progmem sections. For now it is possible to just use [[gnu::progmem]] and read
variables using assembly. My proposal is to:
Use those variables as any other, without creating assembly.
While reading them, compiler has all necessary knowledge where the variable is
and can generate assembly

Possible future improvements:
Automatic placement of variables in __flash sections.
Take care of reading across 64KB boundary
If a variable is const, it can be places automatically in some __flash section

AVR devices are old, but still widely used. This feature could improve code
quality even further.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191009/4b6c8bb5/attachment.html>

Hello Łukasz,

I was wondering if it is possible to implement placing RO variables
within
> progmem sections. For now it is possible to just use [[gnu::progmem]] and
> read variables using assembly
>
This is already implemented, via address spaces. At the moment, the IR
frontend can control which memory to place global variables in by declaring
it with `addrspace(1)`, which will place the variable in read-only program
memory. When omitted, LLVM assumes the default address space 0, which
corresponds to read/write SRAM data memory.

The address space is tracked through all uses of the global variable, and
the AVR backend will correctly select an 'LPM' instruction to load from
program memory when the address space is one, otherwise it will emit an
'LD' instruction to load from data memory. You shouldn't need to
implement
this boilerplate yourself.

There are some good points here

   -
>
>    Automatic placement of variables in __flash sections.
   - avr-rust issue: https://github.com/avr-rust/rust/issues/74
      - I'm a big fan of automatic placement of const/RO variables in flash
      memory, but there hasn't been very much critical debate of it,
which makes
      me hesitant to build it into LLVM proper. As far as my reasoning
has gone,
      I think we should be able to add a pass to do this safely, but whether it
      should be on by default needs more debate IMO
      -
>
>    Take care of reading across 64KB boundary
   - Good point, we don't currently recognize the RAMP{X,Y,Z} IO registers,
      which are required for >64kb addressing.
      -
>
>    If a variable is const, it can be places automatically in some __flash
>    section
   - Related to above - should this be on by default? Is there any possible
      codegen breakage it could cause?



On Thu, Oct 10, 2019 at 3:16 AM Łukasz Kostka via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello.
>
> I was wondering if it is possible to implement placing RO variables within
> progmem sections. For now it is possible to just use [[gnu::progmem]] and
> read variables using assembly. My proposal is to:
>
>    - Use those variables as any other, without creating assembly.
>    - While reading them, compiler has all necessary knowledge where the
>    variable is and can generate assembly
>
>
> Possible future improvements:
>
>    - Automatic placement of variables in __flash sections.
>    - Take care of reading across 64KB boundary
>    - If a variable is const, it can be places automatically in some
>    __flash section
>
>
> AVR devices are old, but still widely used. This feature could improve
> code quality even further.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191125/2bfd2056/attachment.html>

> On Nov 25, 2019, at 00:49, Dylan McKay via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 		• I'm a big fan of automatic placement of const/RO variables in flash
memory, but there hasn't been very much critical debate of it, which makes
me hesitant to build it into LLVM proper. As far as my reasoning has gone, I
think we should be able to add a pass to do this safely, but whether it should
be on by default needs more debate IMO
As I recall, reading a byte from program memory requires an extra cycle. But
maybe if you're cycle counting, you should just be programming in assembly.

Steve

-- 
Stephen Checkoway

Hi.

IMO explicit placing a addrspace(1) is fine. If I decide to port my code to
other platform which does not have those quirks (like 32 bit arm), I could
always use:

For AVR
#define PROGMEM addrspace(1)
For ARM
#define PROGMEM

There may be a use case when someone doesn’t want to automatically place const
variable in program space for performance reasons. IMO simple #define solution
is good enough.

What I care most about, is automatic instruction selection of RAMPZ, LPM,
managing 64KB boundry and letting compiler do it.
That would already greatly simplify code, without a need for hand rolled
assembly for reading and special types. 
> Wiadomość napisana przez Dylan McKay <me at dylanmckay.io> w dniu
25.11.2019, o godz. 06:49:
> 
> Hello Łukasz,
> 
> I was wondering if it is possible to implement placing RO variables within
progmem sections. For now it is possible to just use [[gnu::progmem]] and read
variables using assembly
> 
> This is already implemented, via address spaces. At the moment, the IR
frontend can control which memory to place global variables in by declaring it
with `addrspace(1)`, which will place the variable in read-only program memory.
When omitted, LLVM assumes the default address space 0, which corresponds to
read/write SRAM data memory.
> 
> The address space is tracked through all uses of the global variable, and
the AVR backend will correctly select an 'LPM' instruction to load from
program memory when the address space is one, otherwise it will emit an
'LD' instruction to load from data memory. You shouldn't need to
implement this boilerplate yourself.
> 
> There are some good points here
> Automatic placement of variables in __flash sections.
> avr-rust issue: https://github.com/avr-rust/rust/issues/74
<https://github.com/avr-rust/rust/issues/74>
> I'm a big fan of automatic placement of const/RO variables in flash
memory, but there hasn't been very much critical debate of it, which makes
me hesitant to build it into LLVM proper. As far as my reasoning has gone, I
think we should be able to add a pass to do this safely, but whether it should
be on by default needs more debate IMO
> Take care of reading across 64KB boundary
> Good point, we don't currently recognize the RAMP{X,Y,Z} IO registers,
which are required for >64kb addressing.
> If a variable is const, it can be places automatically in some __flash
section
> Related to above - should this be on by default? Is there any possible
codegen breakage it could cause?
> 
> 
> On Thu, Oct 10, 2019 at 3:16 AM Łukasz Kostka via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hello.
> 
> I was wondering if it is possible to implement placing RO variables within
progmem sections. For now it is possible to just use [[gnu::progmem]] and read
variables using assembly. My proposal is to:
> Use those variables as any other, without creating assembly.
> While reading them, compiler has all necessary knowledge where the variable
is and can generate assembly
> 
> Possible future improvements:
> Automatic placement of variables in __flash sections.
> Take care of reading across 64KB boundary
> If a variable is const, it can be places automatically in some __flash
section
> 
> AVR devices are old, but still widely used. This feature could improve code
quality even further.
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191125/835a69fa/attachment-0001.html>

Sorry if I’m chiming in with an irrelevant comment :) … but placing read only
variables (in C, const variables) in program memory/flash is also one of those
things that I think has been discussed in fairly great detail by the AVR GCC
guys when they were building their original compiler.  I’m pretty sure I
remember coming across old threads on this.

They discuss it here: https://www.nongnu.org/avr-libc/user-manual/pgmspace.html
<https://www.nongnu.org/avr-libc/user-manual/pgmspace.html>. They are
talking about C but it would probably be relevant more generally?

They seemed to have lots of good reasons why it was not optimal compiler design
and the person writing the program should explicitly define when a constant
should be defined in program memory.



Certainly on the most basic level, for anything except strings, these constants
will only amount to a very small proportion of the code size, wouldn’t they?

It makes sense for the frontend to reason about storage if enough is known and I
would think the frontend is the right place to add any such logic.

(As an example, in a future version of the swift compiler for targeting AVR, I
want to make it automatically intern strings as C strings and add addrspace(1)
to them.)


Just my 2 cents worth… I know far less than you guys :)…



Carl

> On 25 Nov 2019, at 05:49, Dylan McKay via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hello Łukasz,
> 
> I was wondering if it is possible to implement placing RO variables within
progmem sections. For now it is possible to just use [[gnu::progmem]] and read
variables using assembly
> 
> This is already implemented, via address spaces. At the moment, the IR
frontend can control which memory to place global variables in by declaring it
with `addrspace(1)`, which will place the variable in read-only program memory.
When omitted, LLVM assumes the default address space 0, which corresponds to
read/write SRAM data memory.
> 
> The address space is tracked through all uses of the global variable, and
the AVR backend will correctly select an 'LPM' instruction to load from
program memory when the address space is one, otherwise it will emit an
'LD' instruction to load from data memory. You shouldn't need to
implement this boilerplate yourself.
> 
> There are some good points here
> Automatic placement of variables in __flash sections.
> avr-rust issue: https://github.com/avr-rust/rust/issues/74
<https://github.com/avr-rust/rust/issues/74>
> I'm a big fan of automatic placement of const/RO variables in flash
memory, but there hasn't been very much critical debate of it, which makes
me hesitant to build it into LLVM proper. As far as my reasoning has gone, I
think we should be able to add a pass to do this safely, but whether it should
be on by default needs more debate IMO
> Take care of reading across 64KB boundary
> Good point, we don't currently recognize the RAMP{X,Y,Z} IO registers,
which are required for >64kb addressing.
> If a variable is const, it can be places automatically in some __flash
section
> Related to above - should this be on by default? Is there any possible
codegen breakage it could cause?
> 
> 
> On Thu, Oct 10, 2019 at 3:16 AM Łukasz Kostka via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hello.
> 
> I was wondering if it is possible to implement placing RO variables within
progmem sections. For now it is possible to just use [[gnu::progmem]] and read
variables using assembly. My proposal is to:
> Use those variables as any other, without creating assembly.
> While reading them, compiler has all necessary knowledge where the variable
is and can generate assembly
> 
> Possible future improvements:
> Automatic placement of variables in __flash sections.
> Take care of reading across 64KB boundary
> If a variable is const, it can be places automatically in some __flash
section
> 
> AVR devices are old, but still widely used. This feature could improve code
quality even further.
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191125/0625a16f/attachment.html>