Steven Bosscher wrote:
On 3/28/07, Julian Brown <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote:
> All of this feels (to me anyway) like adding a lot of code to the
> middle end to support MEP specific arch features. I understand it is
> in the mission statement that more ports is a goal for GCC, but I
> wonder if this set of changes is worth the maintenance burden...
FWIW, it sounds to me like this feature may also be useful for current
iterations of the ARM NEON extension (which we're planning to submit
support for quite soon). NEON supports various operations on DImode
quantities, but we don't use them for normal code at present because
moving values from NEON back to ARM core registers is relatively slow,
so we want to avoid doing that as far as possible.
So, if there was a way of specifying that a particular value should be
kept in a NEON register, that'd be a good thing, I think.
And if you use this coprocessor hackery, it will be exactly what Ian
opposed in his first reply: "As far as I can see you're using new
modes to drive register class preferences."
Quite possibly. I don't really know enough about how any of this works
to say much useful, it just seemed like another potential use for the
feature (albeit a rather esoteric one) if it does go in.
Cheers,
Julian
