[x86] why llvm keep rodata.const section

[LukeSTM]

https://godbolt.org/z/r8ha9o9nf

compile option: -O2 -ffunction-sections -fdata-sections -mno-sse

#include <stdio.h>
#include <string.h>                                                                                                                                             
 
struct ss_t {
	int s_id;
	char msg[];
};

struct ss_t *mst_1;

void do_some_test(void)
{
	struct ss_t *mst_2;
	char buf[100];
	int fill_num=4;
	char tmp_str[40]="test stringssssssssss!";
	memcpy(buf,&fill_num,sizeof(int));
	memcpy(buf+sizeof(int), tmp_str, strlen(tmp_str) + 1); 
	mst_1=(struct ss_t *)buf;
 
	if (mst_1->s_id==4)
		printf("mst_1->s_id=%d,mst_1->msg=%s\n",mst_1->s_id,mst_1->msg);
}

sorry, but i want know, why clang keep .rodata..L__const.do_some_test.tmp_str in sections. Constant could be expanded into movabsq instructions, and what would use .rodata..L__const.do_some_test.tmp_str? Dose it should be removed ?

[LukeSTM]

CC @MaskRay

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: Luke (LukeSTM)

https://godbolt.org/z/r8ha9o9nf

compile option: -O2 -ffunction-sections -fdata-sections -mno-sse

#include <stdio.h>
#include <string.h>                                                                                                                                             
 
struct ss_t {
	int s_id;
	char msg[];
};

struct ss_t *mst_1;

void do_some_test(void)
{
	struct ss_t *mst_2;
	char buf[100];
	int fill_num=4;
	char tmp_str[40]="test stringssssssssss!";
	memcpy(buf,&fill_num,sizeof(int));
	memcpy(buf+sizeof(int), tmp_str, strlen(tmp_str) + 1); 
	mst_1=(struct ss_t *)buf;
 
	if (mst_1->s_id==4)
		printf("mst_1->s_id=%d,mst_1->msg=%s\n",mst_1->s_id,mst_1->msg);
}

sorry, but i want know, why clang keep .rodata..L__const.do_some_test.tmp_str in sections. Constant could be expanded into movabsq instructions, and what would use .rodata..L__const.do_some_test.tmp_str? Dose it should be removed ?

[efriedma-quic]

I briefly looked; I think what's happening is that the accesses to the string are getting removed, but it happens too late for the relevant passes to remove the global. I'd expect the linker to eliminate the string at link time.