<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">They discuss it here: <a href="https://www.nongnu.org/avr-libc/user-manual/pgmspace.html" class="">https://www.nongnu.org/avr-libc/user-manual/pgmspace.html</a>. They are talking about C but it would probably be relevant more generally?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">(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.)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Just my 2 cents worth… I know far less than you guys :)…</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Carl</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25 Nov 2019, at 05:49, Dylan McKay via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hello Łukasz,</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="">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<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">There are some good points here<br class=""></div><div class=""><ul class=""><li class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Automatic placement of variables in __flash sections.</blockquote><div class=""><ul class=""><li class="">avr-rust issue: <a href="https://github.com/avr-rust/rust/issues/74" class="">https://github.com/avr-rust/rust/issues/74</a></li><li class="">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<br class=""></li></ul></div></li><li class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Take care of reading across 64KB boundary</blockquote><div class=""><ul class=""><li class="">Good point, we don't currently recognize the RAMP{X,Y,Z} IO registers, which are required for >64kb addressing.<br class=""></li></ul></div></li><li class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If a variable is const, it can be places automatically in some __flash section</blockquote></li><ul class=""><li class="">Related to above - should this be on by default? Is there any possible codegen breakage it could cause?</li></ul></ul><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2019 at 3:16 AM Łukasz Kostka via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class="">Hello.<div class=""><br class=""></div><div class="">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:</div><div class=""><ul class=""><li class="">Use those variables as any other, without creating assembly.</li><li class="">While reading them, compiler has all necessary knowledge where the variable is and can generate assembly</li></ul><div class=""><br class=""></div></div><div class="">Possible future improvements:</div><div class=""><ul class=""><li class="">Automatic placement of variables in __flash sections.</li><li class="">Take care of reading across 64KB boundary</li><li class="">If a variable is const, it can be places automatically in some __flash section</li></ul><div class=""><br class=""></div></div><div class="">AVR devices are old, but still widely used. This feature could improve code quality even further. </div><div class=""><br class=""></div></div>_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>