<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 9/21/2018 3:05 AM, David Spickett
via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:VI1PR08MB0975863A147A32D6A10EF21C9C120@VI1PR08MB0975.eurprd08.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt;
color:rgb(0,0,0);
font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple
Color Emoji","Segoe UI
Emoji",NotoColorEmoji,"Segoe UI
Symbol","Android Emoji",EmojiSymbols">
<div>Hi,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I look forward to your feedback.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
One thing this doesn't mention is clang's "target" attribute for
functions; have you considered that at all?<br>
<br>
<blockquote type="cite"
cite="mid:VI1PR08MB0975863A147A32D6A10EF21C9C120@VI1PR08MB0975.eurprd08.prod.outlook.com">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt;
color:rgb(0,0,0);
font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple
Color Emoji","Segoe UI
Emoji",NotoColorEmoji,"Segoe UI
Symbol","Android Emoji",EmojiSymbols">
<div>
ARM and AArch64:<br>
- Make the TargetParser the single source for extension names,
removing the AsmParser tables.<br>
- Reject unknown extension names with a diagnostic that
includes a list of valid extensions for that architecture/CPU.<br>
- Reject invalid combinations of architecture/CPU and
extensions with an error diagnostic.<br>
- 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.<br>
- Emit a warning when a mandatory feature of the base
architecture is enabled with '+extension', or disabled with
'+noextension'. (and ignore the option)<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:VI1PR08MB0975863A147A32D6A10EF21C9C120@VI1PR08MB0975.eurprd08.prod.outlook.com">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt;
color:rgb(0,0,0);
font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple
Color Emoji","Segoe UI
Emoji",NotoColorEmoji,"Segoe UI
Symbol","Android Emoji",EmojiSymbols">
<div>
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:<br>
1. create a new LLVMTargetParser library that contains all
parsers for architectures that use it.<br>
2. put the TargetParser for each backend in the library group
for that backend. This requires one of:<br>
* Relaxing the requirement that target parsers must be
built even if the backend is not.<br>
* Modifying the CMake scripts to build the target parsers
even if the backend is not being built.<br>
</div>
</div>
</blockquote>
<br>
Maybe you could put it into some existing library, like
libLLVMTarget.<br>
<br>
<blockquote type="cite"
cite="mid:VI1PR08MB0975863A147A32D6A10EF21C9C120@VI1PR08MB0975.eurprd08.prod.outlook.com">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt;
color:rgb(0,0,0);
font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple
Color Emoji","Segoe UI
Emoji",NotoColorEmoji,"Segoe UI
Symbol","Android Emoji",EmojiSymbols">
<div>
"Negative" Backend Features<br>
===========================<br>
<br>
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).<br>
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.<br>
<br>
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.<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
Also, these aren't the only negative features... although maybe
they're the only negative features that are relevant for
TargetParser?<br>
<br>
-Eli<br>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
</body>
</html>