core changes for mep port

[Julian Brown]

Steven Bosscher wrote:
> On 3/28/07, Julian Brown <julian@codesourcery.com> 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