[AVR] Support the '__flash' attribute

[Quuxplusone]

Bugzilla Link	PR31568
Status	RESOLVED FIXED
Importance	P normal
Reported by	Dylan McKay (me@dylanmckay.io)
Reported on	2017-01-06 23:39:55 -0800
Last modified on	2021-04-10 03:00:41 -0700
Version	trunk
Hardware	All All
CC	anastasia.stulova@arm.com, anton@korobeynikov.info, david.hebbeker@gmail.com, llvm-bugs@lists.llvm.org, powerman1st@163.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Support for the '__flash' keyword will need to be added in order to place data into program memory.

The parser will need to be modified to understand the keyword and then place data into the progmem address space.

Examples of LLVM IR placing variables in the program memory can be found in 'test/CodeGen/AVR/progmem.ll' in LLVM.

http://www.atmel.com/webdoc/AVRLibcReferenceManual/porting_1iar_porting_flash.html

[Quuxplusone]

Can't you simply define flash as attribute__((section("foo"))

[Quuxplusone]

The only thing required to place a variable into flash memory is to place it into address space '1'.

If we solely place the variable into a specific section, we won't be able to access it correctly because AVR (bring of the Harvard architecture) has separate instructions for accessing program memory, and accessing main memory.

[Quuxplusone]

Ok. Do we have an attribute to specify an address space?

[Quuxplusone]

I don't think so, but there are parallels to this attribute in the OpenCL backend.

http://clang.llvm.org/docs/AttributeReference.html#opencl-address-spaces

[Quuxplusone]

Clang supports an address_space attribute i.e. you could just define:

define flash attribute__((address_space(1)))

This attribute is undocumented unfortunately.

Or if you need to support __flash as a keyword you can simply map to address_spaces early in the parser. This is what we do in OpenCL for global, local, constant, generic.

[Quuxplusone]

I have made a patch to make flash as a builtin macro attribute((addrspace(1))), along with error message if flash is not used the same way as gcc expected.

https://reviews.llvm.org/D96853

[Quuxplusone]

fixed in https://reviews.llvm.org/rG4f173c0c42d02b14ab388a826ef0d463a07d7953