https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915
--- Comment #8 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- (In reply to Evandro Menezes from comment #5) > Created attachment 33249 [details] > Dhrystone, part 2 of 3 > > I firstly observed this issue when looking into Dhrystone built with fairly > standard options: > > -O2 -fno-short-enums -fno-inline -fno-inline-functions > -fno-inline-small-functions -fno-inline-functions-called-once > -fomit-frame-pointer -funroll-all-loops > > If I add -mno-lra, the code size in dhry_1.o is about 2% smaller. Evandro, thanks for reporting this. Sorry, I am busy with other thing these days. I'll start to work on this PR in September to try to make some progress for the next GCC release. May be a better remeaterialization in LRA I am working on now will help the PR too. (In reply to Evandro Menezes from comment #7) > (In reply to Vladimir Makarov from comment #6) > > > > Evandro, thanks for reporting this. Sorry, I am busy with other thing these > > days. I'll start to work on this PR in September to try to make some > > progress for the next GCC release. > > > > May be a better remeaterialization in LRA I am working on now will help the > > PR too. > > Vladimir, > > I was thinking about using the hook function to avoid using FPR, at least > when -Os is specified, for the time being. This way, registers would still > be allocated by the LRA, but this side-effect would be under control. Or do > y'all think that it's better to wait a little while longer? If it works and it is ok for ARM mainteiners, it is ok for me too. I will look at this with the point of LRA, can be the code decreased or not. Your solution is on the machine-dependent part. So it is up to you and ARM maintainers. I think you should not wait for what I may or may not find in LRA itself to fix it.
