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

Friedman, Eli via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 21 11:05:35 PDT 2018

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?


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>

More information about the llvm-dev mailing list