Re: [PATCH] clang compatibility: MCR/MRC syntax

Sorry for the delay dealing with this, I needed to work through some issues with it.

The changes to use MRC with P15 are fine.

I don't especially like the open-coding of the ADRL, but it seems in fact, to be unnecessary.  If we align `register_names` to a 4-byte boundary, then we can use a simple ADR instruction (as the MOV can now use a value that is in the range 0-1020 when it is a multiple of 4).

But secondly, and most importantly, the change to add :lower16: is incorrect, on several counts.  This looks like a clang bug to me...
1) The :lower16: isn't allowed by GAS on a MOV instruction, it must be a MOVW.
2) The :lower16: would cause us to miss an out-of-range value as we would simply discard any excess bits, leading to wrong code
3) There's no need for a MOVW anyway as the difference is just 308 with the current code and fits within a simple (traditional) MOV instruction just fine.

So I've taken that bit out and made the change to the ADR as described above and pushed those changes.

R.

On 20/01/2025 15:30, Volodymyr Turanskyy wrote:
> Hi,
> 
>  
> 
> Please see attached re-formatted patch file.
> 
>  
> 
> Sincerely,
> 
>  
> 
> *Volodymyr Turanskyy* | Principal Software Engineer | CE SW LLVM Team
> 
>  
> 
> *From: *Richard Earnshaw <[email protected]>
> *Date: *Monday, 20 January 2025 at 15:23
> *To: *Volodymyr Turanskyy <[email protected]>, [email protected] <[email protected]>
> *Cc: *nd <[email protected]>
> *Subject: *Re: [PATCH] clang compatibility: MCR/MRC syntax
> 
> On 20/01/2025 15:09, Richard Earnshaw (lists) wrote:
>> On 20/01/2025 14:46, Volodymyr Turanskyy wrote:
>>> Hi,
>>>
>>>  
>>>
>>> Following up on the RFC [1], please find attached a patch with some clean up:
>>>
>>>   * Use mrc p15 co-processor instruction syntax.
>>>   * Replace adrl that is not supported in Thumb mode with add.
>>>   * Explicitly specify :lower16: for taking address.
>>>
>>>  
>>>
>>> References
>>>
>>>  1. https://sourceware.org/pipermail/newlib/2025/021452.html <https://sourceware.org/pipermail/newlib/2025/021452.html> <https://sourceware.org/pipermail/newlib/2025/021452.html <https://sourceware.org/pipermail/newlib/2025/021452.html>>
>>>
>>>  
>>>
>>>  
>>>
>>> Sincerely,
>>>
>>>  
>>>
>>> *Volodymyr Turanskyy* | Principal Software Engineer | CE SW LLVM Team
>>>
>> 
>> 
>> This is OK apart from:
>> 
>> -    mov         r7, #(VectorCode_Limit - VectorCode)
>> +    mov         r7, #:lower16:(VectorCode_Limit - VectorCode)
>> 
>> which has the problem that it implies the presence of MOVW (ie armv6t2 or later); I believe we currently support all architectures from v4 upwards.  What is the problem that the LLVM assembler can't handle here?  The difference between these two locations should be small enough that we don't need anything beyond a simple MOV instruction.
>> 
>> R.
> 
> 
> 
> Hmm, ignore that.  The entire contents of this file is already gated on being built on armv7-a, so that shouldn't be a problem.
> 
> R.
>