Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx

["Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>]

On 24/05/17 17:19, Richard Earnshaw (lists) wrote:
> On 24/05/17 17:03, Jim Wilson wrote:
>> On Wed, May 24, 2017 at 8:17 AM, Richard Earnshaw (lists)
>> <Richard.Earnshaw@arm.com> wrote:
>>> On 24/05/17 15:18, Jim Wilson wrote:
>>>> On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists)
>>>> <Richard.Earnshaw@arm.com> wrote:
>>>>> OK.  does this need to go in the gcc-8 changes file?
>>>>
>>>> Falkor hasn't shipped yet.  I'm dropping features that only existed in
>>>> preproduction NDA hardware, so there isn't anything end user visible,
>>>> and hence I don't think that it needs to be in the release notes.
>>>>
>>>> Jim
>>>>
>>>
>>> Fair enough, so what about a minimal back-port to GCC-7 that just
>>> disables the CPU name for aarch32?
>>
>> Not sure how to do that.  If I remove the arm-cpus.in entry, then 5
>> files get automatically regenerated.  That leaves us with a few minor
>> inconsistencies in specs handling and multilibs which are harmless but
>> we may as well fix anyways.  The only part of the patch that is
>> optional if the part which moves the qdf24xx_extra_costs array from
>> the arm dir to the aarch64 dir.  So the minimal patch ends up being
>> half the size of the original patch, changing 9 of the original 11
>> files, which isn't very minimal.
>>
>> Another option might be to just remove the documentation and leave the
>> code in, i.e. only apply the doc/invoke.texi patch.  That would be a
>> small and safe patch.
>>
>> Jim
>>
> 
> Certainly we should remove it from the documentation.  That might be the
> best idea.
> 
> I don't really regard the size of the changes to the auto-generated code
> as being relevant - if we put the generated code directly in the build
> directory and treated it like we do the output from gen*.c, then those
> changes would never be even noticed.
> 
> R.
> 

Having pondered this over night, I think the lowest risk thing to do,
provided it applies cleanly to the gcc-7 branch, is just commit the
entire patch on the branch and be done with it.  The risk from removing
this code is pretty minimal and removing it all is the best way of
avoiding things like unexpected compiler warnings breaking the build.
If it doesn't apply cleanly, then just drop the documentation.

R.