This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch,avr] PR78883: Implement CANNOT_CHANGE_MODE_CLASS.
On Tue, Jan 03, 2017 at 01:43:01PM +0000, Richard Sandiford wrote:
> An alternative would be to add a new macro to control this block in
> general_operand:
>
> #ifdef INSN_SCHEDULING
> /* On machines that have insn scheduling, we want all memory
> reference to be explicit, so outlaw paradoxical SUBREGs.
> However, we must allow them after reload so that they can
> get cleaned up by cleanup_subreg_operands. */
> if (!reload_completed && MEM_P (sub)
> && GET_MODE_SIZE (mode) > GET_MODE_SIZE (GET_MODE (sub)))
> return 0;
> #endif
>
> The default would still be INSN_SCHEDULING, but AVR could override it
> to 1 and reject the same subregs.
Or you can define INSN_SCHEDULING (by defining a trivial automaton for
your port: a define_automaton, a define_cpu_unit for that automaton, and
a define_insn_reservation for that unit).
It would be nice if we could separate "no subregs of memory" from "has
instruction scheduling". Or ideally subregs of memory would just go away
completely.
> That would still be a hack, but at least it would be taking things in
> a good direction. Having different rules depending on whether targets
> define a scheduler is just a horrible wart that no-one's ever had chance
> to fix. If using the code above works well on AVR then that'd be a big
> step towards making the code unconditional.
Ugh, it sounds like I am volunteering. Oh well.
> It'd definitely be worth checking how it affects code quality though.
It shouldn't be too bad, if ports that do have instruction scheduling can
live without it.
> (Although the same goes for the current patch, since C_C_M_C is a pretty
> big hammer.)
Yeah, and the current patch disallows much more than is needed here, even.
Segher