[llvm-dev] [RFC] New Clang target selection options for ARM/AArch64

[Friedman, Eli via llvm-dev]

On 9/21/2018 3:05 AM, David Spickett via llvm-dev wrote:
> Hi,
>
> Below is a document detailing changes we'd like to make to Clang/LLVM 
> to improve the usability of the target options for ARM and AArch64.
>
> To keep things simple the proposed changes are listed at the start and 
> you can find the supporting examples at the end of the document.
>
> I look forward to your feedback.

This looks like you've put a lot of thought into it; I have some minor 
comments on the details, but I think this is looking in the right direction.

One thing this doesn't mention is clang's "target" attribute for 
functions; have you considered that at all?

> ARM and AArch64:
> - Make the TargetParser the single source for extension names, 
> removing the AsmParser tables.
> - Reject unknown extension names with a diagnostic that includes a 
> list of valid extensions for that architecture/CPU.
> - Reject invalid combinations of architecture/CPU and extensions with 
> an error diagnostic.
> - Add independent subtarget features for each extension so that 
> v8.x+1-a extensions can be used individually with earlier v8.x-a 
> architectures where allowed.
> - Emit a warning when a mandatory feature of the base architecture is 
> enabled with '+extension', or disabled with '+noextension'. (and 
> ignore the option)

Could you go into a bit more detail about mandatory features?  I'm 
pretty sure people are using the extension functionality to turn off 
features which are technically mandatory according to the reference 
manual, like floating-point in armv8a.

> To do this, we would need to move TargetParser to break the cyclic 
> dependency of LLVMSupport -> llvm-tblgen -> LLVMSupport. There are 2 
> options for this:
> 1. create a new LLVMTargetParser library that contains all parsers for 
> architectures that use it.
> 2. put the TargetParser for each backend in the library group for that 
> backend. This requires one of:
>     * Relaxing the requirement that target parsers must be built even 
> if the backend is not.
>     * Modifying the CMake scripts to build the target parsers even if 
> the backend is not being built.

Maybe you could put it into some existing library, like libLLVMTarget.

> "Negative" Backend Features
> ===========================
>
> There are a couple of features in ARM which remove capabilities rather 
> than adding them. These are 'd16' (removes the top 16 D registers) and 
> 'fp-only-sp' (removes double precision).
> It would simplify the implementation if those were replaced with 
> positive options. As in one that adds the top 16 D registers and one 
> that enables double precision operations.
>
> This is a relatively simple change to LLVM but it will effect a large 
> number of tests and would be a breaking change for users of LLVM as a 
> library.

This seems mostly orthogonal?  At least I mean, I guess it might make 
the translation from TargetParser features to LLVM features slightly 
easier, but it seems like there could be some unexpected implications, 
so I don't want to tie it to this change.  If you think it's really 
worthwhile, please make sure it's a separate patch.

Also, these aren't the only negative features... although maybe they're 
the only negative features that are relevant for TargetParser?

-Eli


-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180921/8bcb0c14/attachment.html>