Am 03.07.24 um 21:39 schrieb Jeff Law:
On 7/3/24 1:26 PM, Georg-Johann Lay wrote:
Am 02.07.24 um 15:48 schrieb Richard Biener:
On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay <a...@gjlay.de> wrote:
Hi Jeff,
This is a patch to get correct code out of 64-bit
loads from address-space __memx.
The AVR address-spaces may require that move insns issue
calls to library support functions, a fact that -ftree-ter
doesn't account for. tree-ssa-ter.cc then replaces an
expression across such a library call, resulting in wrong code.
This patch disables that pass per default on avr, as there is no
more fine grained way to avoid malicious optimizations.
The pass can still be re-enabled by means of explicit -ftree-ter.
Ok to apply?
I think this requires more details on what goes wrong - I assume
it's not stmt reordering that effectively happens but recursive
expand_expr on SSA defs when those invoke libcalls? In that
case this would point to a deeper issue.
The difference is that with TER, we get a hard reg in .expand
for a movdi from 24-bit address-space __memx.
Such moves require library calls, which in turn require
specific hard registers. As avr backend has no movdi, the
moddi gets expanded as 8 * movqi, and that does not work
when the target registers are hard regs, as some of them
are clobbered by the libcalls.
But this is something that's handled for other targets. I don't
remember all the details, but there's generic code to handle this
situation.
Jeff
A libcall in a move insn? How would the middle-end know that?
Johann
