varasm.cc: how to hook in assemble_variable ?
The avr backend supports variable attributes like the following that
allow to define symbols:
__attribute__((address(1234))
char a_symbol;
would produce assembly
.global a_symbol
a_symbol = 1234
This works except for -fdata-sections -fno-common (PR112952), and I am
struggling to find a fix.
Currently, the asm out happens in ASM_OUTPUT_ALIGNED_DECL_LOCAL and
ASM_OUTPUT_ALIGNED_DECL_COMMON, which is bypassed with above options.
With -fdata-sections -fno-common there is no way to output the code
in the way as required by the attributes.
The only way I found is to output in TARGET_ENCODE_SECTION_INFO
(resp. cache for later output) and set TREE_ASM_WRITTEN(decl) = 1
in order to bypass the rest of assemble_variable().
However, varasm.cc::assemble_variable() would require an extension:
The function currently reads something like below, where lines
marked with ! are needed to make it work:
void
assemble_variable (tree decl, int top_level ATTRIBUTE_UNUSED,
int at_end ATTRIBUTE_UNUSED, int dont_output_data)
{
...
/* The first declaration of a variable that comes through this function
decides whether it is global (in C, has external linkage)
or local (in C, has internal linkage). So do nothing more
if this function has already run. */
if (TREE_ASM_WRITTEN (decl))
return;
/* Make sure targetm.encode_section_info is invoked before we set
ASM_WRITTEN. */
decl_rtl = DECL_RTL (decl);
TREE_ASM_WRITTEN (decl) = 1;
! /* Allow targetm.encode_section_info to output all of decl
! including alignment, globalizing and initializer its own
! way. */
! if (TREE_ASM_WRITTEN (decl))
!return;
/* Do no output if -fsyntax-only. */
if (flag_syntax_only)
return;
What's the proposed way to fix this?
Thanks in advance,
Johann
FYI, what won't work is to set TREE_ASM_WRITTEN in insert_attributes
for several reasons.
Re: Request for Direction.
Thx, I appreciate the direction. We used a special tag in the preprocessor that we did. But there is no requirement of any specific means or syntax. we have been calling content addressable variables "sarts". So the first thing we must do is take almost any existing variable and identify it as a sart - that would be an attibute. But it must also belong to a specific group/block/ Name spaces could deal with this, but depending on the problem there could be one namespace for all CA variables or many different namespaces. Basically the variable must be identified as content addressable, and it must be tagged as utilizing a specific address translation mechanism. The next issue is that when the variable is used any type of bounds checking must be disabled because the "bounds" of a sart or content addressible variable are not easily known by the compiler. Next the code generated for get/put will be different. On Mon, 2023-12-18 at 08:59 +0100, Richard Biener via Gcc wrote: > On Sat, Dec 16, 2023 at 11:53 PM Jonathan Wakely via Gcc > wrote: > > > > On Sat, 16 Dec 2023 at 22:41, David H. Lynch Jr. wrote: > > > I am looking for any help I can get - pointers as to where to > > > start > > > with GCC, docs or howto's through to someone that wishes to > > > participate > > > in the project. There is a potential for compensation - we are > > > seeking > > > a grant, though our long term goals are partnership with a Memory > > > vendor. > > > > I would start with https://gcc.gnu.org/wiki/GettingStarted > > and the docs it links to at > > https://gcc-newbies-guide.readthedocs.io/en/latest/ > > You might also want to look at named address spaces, though they > are tracked as qualifiers. Generally annotations to declarations are > easiest as custom attributes, though I would guess you need to > be able to annotate pointer (types) as well, thus my hint with the > address-spaces. I guess handling all Content addressable variables > as being in a single special address space isn't enough of > information > to address them. > > Richard. > > > This list is the place to ask if you get stuck, or the #gcc channel > > on > > the OFTC IRC network.
Re: Request for Direction.
For now I just need to be able to impliment something relatively simply so that we can write take some existing applications - such as AI, or sparse arrays or and demonstrate/test end to end our concept. If it is successful and various others think there is a better syntax, or means of implimenting that is a future problem. On Mon, 2023-12-18 at 08:59 +0100, Richard Biener wrote: > On Sat, Dec 16, 2023 at 11:53 PM Jonathan Wakely via Gcc > wrote: > > > > On Sat, 16 Dec 2023 at 22:41, David H. Lynch Jr. wrote: > > > I am looking for any help I can get - pointers as to where to > > > start > > > with GCC, docs or howto's through to someone that wishes to > > > participate > > > in the project. There is a potential for compensation - we are > > > seeking > > > a grant, though our long term goals are partnership with a Memory > > > vendor. > > > > I would start with https://gcc.gnu.org/wiki/GettingStarted > > and the docs it links to at > > https://gcc-newbies-guide.readthedocs.io/en/latest/ > > You might also want to look at named address spaces, though they > are tracked as qualifiers. Generally annotations to declarations are > easiest as custom attributes, though I would guess you need to > be able to annotate pointer (types) as well, thus my hint with the > address-spaces. I guess handling all Content addressable variables > as being in a single special address space isn't enough of > information > to address them. > > Richard. > > > This list is the place to ask if you get stuck, or the #gcc channel > > on > > the OFTC IRC network.
