Richard Sandiford wrote:
Nigel Stephens <nigel@xxxxxxxx> writes:
I have a patch against gcc-3.4 <snip>
If people really don't like the inline expansion, then maybe it could be
enabled or disabled by a new -m option.
IMO, controlling with optimize_size would be enough.
Yes, that sounds right.
But it sounds from your description like the patch just adds a new hard-coded multi-insn asm string. Is that right? If so, I'd really like to avoid that.
Yes, and I totally agree with you.
It would much better IMO if we handle this in the target-independent parts of the compiler. We can already open-code certain non-native operations, it's "just" that wide shifts are a missing case.
If we handle it in a target-independent way, with each insn exposed
separately, we will be able to optimize special cases better.
We'll also get the usual scheduling benefits.
I agree that we should open-code it for the obvious reasons, but does it have to be target independent, or could/should we prototype it with define_expand?
Nigel
