https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112830
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Georg-Johann Lay from comment #15) > (In reply to Richard Biener from comment #13) > > The master branch has been updated by Richard Biener <rgue...@gcc.gnu.org>: > > > > https://gcc.gnu.org/g:68d32d02035fc081384ec6d6fd275e49ffa5d016 > > > > commit r14-6182-g68d32d02035fc081384ec6d6fd275e49ffa5d016 > > Author: Richard Biener <rguent...@suse.de> > > Date: Mon Dec 4 10:35:38 2023 +0100 > > > > middle-end/112830 - avoid gimplifying non-default addr-space assign to > > memcpy > > > > The following avoids turning aggregate copy involving non-default > > address-spaces to memcpy since that is not prepared for that. > > avr.md cpymemhi currently only accepts const_int sizes. Does your change > mean it's not possible (or unsafe) to implement that insn with variable > sizes for better code? > > The middle end still tries to expand cpymemhi for variable sizes (but > currently the expander FAILs), so I think I don't understand that part of > the commit message. It specifically avoids expanding __builtin_memcpy since that goes off rails, losing address-space info. And a user using memcpy () himself for copying between address-spaces is doing invalid things anyway. The middle-end should still try to use cpymem and as fallback will emit a loop IIRC. Tuning from within the backend should be still possible, also for variable-size. It might be the middle-end needs improvements as well, feel free to open new bugreports with testcases where things do not work as expected from the middle-end side.
