[PATCH v3] RISC-V: Enable dead code elimination

[Zhangjin Wu]

Hi, Conor. 

> Hi, 
> 
> On Sun, May 21, 2023 at 08:41:34PM +0800, Zhangjin Wu wrote:
> > > On Wed, May 17, 2023 at 04:29:36PM +0800, Zhangjin Wu wrote:
> > > > Select CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION for RISC-V, allowing
> > > > the user to enable dead code elimination. In order for this to work,
> > > > ensure that we keep the alternative table by annotating them with KEEP.
> > > >
> > > > This boots well on qemu with both rv32_defconfig & rv64 defconfig, but
> > > > it only shrinks their builds by ~1%, a smaller config is thereforce
> > > > customized to test this feature:
> > >
> > > OOPS, I didn't noticed that you have sent out the patch and you are now
> > > in v3. I may read your patch sevral months ago, but I forget it.
> >
> > Yeah, I have sent this patch several times, but beside the suggestion from
> > conor,
> 
> Half the time my comments are just me forwarding on stuff from
> automation complaining. Otherwise I do my best to look at things that
> are being ignored.
> 
> > I have gotten no more responses (before v3), I even thought RISC-V
> > people are not interested in or not require size shrinking ;-)
> 
> IIRC, you sent a standalone patch, which might've been picked up had you
> not followed it up with a series marked RFC containing the same patch.
> The v2 which was sent on 14/2 was marked superseded after the RFC series
> on 17/2. And I guess since the RFC generated no comments, but clearly
> couldn't be merged, it was ignored?
>

Yeah, v2 has no feedback (I have put it in the dead syscall elimination
series who depends on it), so, I rebased it on latest v6.4-rc2
and send a v3 ;-)

Btw, where can I check the patch status? 10 years ago, when I worked on
MIPS architecture, I used patchwork to track the status, not sure, which
web site we are currently using, lore.kernel.org or still
patchwork.kernel.org? I use lore to read and send patches now.

> To be honest, I am not quite sure why you are sending some of these
> things as RFC. The VDSO thing looks like something that should be
> considered/reviewed properly etc, rather than "hey I have this idea,
> does anyone have suggestions".
>

"RFC" added in my recent patchset is really want to get some feedbacks,
especially, to learn if it is valuable to continue. As you know, the
VDSO is required by most of the system, so, touch it should be
carefully, and dead syscall elimination is another "big" change.

Thanks for your kindly suggestion, I will remove "RFC" if it is not that
necessary.

> > As I can see from the mailing list, Guoren just sent out a new series of
> > patchset [0] about size shrink (-16%), and include the one [1] from you, so,
> > I'm not alone, the left patchsets I'm working on and upstreaming include dead
> > syscall elimination [2], vdso configuration [3], nolibc for rv32 [4] and even
> > the self-decompress vmlinuz support (RFC v1 will be sent out next week), all of
> > these patchsets are result of my tinylinux [5] porting to RISC-V (got 334k
> > non-MMU rv64 vmlinuz+nolibc hello).
> 
> Ordinarily I would suggest that you contact these people and ask them to
> review your work, so that there is less for Palmer to do when he is
> going through the list on patchwork for stuff to merge - but it looks
> like you are already doing that, which is great :)
>

Yeah, In the past 2 or 3 months, I'm focusing on implementing the other
tinylinux patchsets for RISC-V, and have no enough time to ping
reviewers ;-)

> > I have found that you have fixed up some other issues, It is better to
> > merge mine in your series, please don't forget the Tested-by line from
> > Bin Meng [7] and the Reviewed-by line from Guoren [8].
> 
> I'll mark this patch as superseded then, yeah?
> 

Yes, of course.

Thanks,
Zhangjin

> Thanks,
> Conor.