<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2020 at 2:28 PM Simon Cook via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 16/01/2020 18:01, Alex Bradbury via llvm-dev wrote:<br>
> <br>
> I believe this situation is somewhat new to LLVM, as typically work on new ISA<br>
> extensions/revisions is performed behind closed doors until the final version<br>
> is announced.<br>
> <br>
> There are multiple options for inclusion of an unratified standard extension<br>
> upstream:<br>
> 1) Feature is in-tree, but only compiled with an explicit flag. Guarding by<br>
>   ifdefs is likely to get ugly, and this also requires extra build bots<br>
>   etc.<br>
> 2) Feature always compiled, but the code path to enable it is disabled<br>
>   without a particular build flag. Also needs extra build bots.<br>
> 3) Feature is always compiled and can be enabled regardless of LLVM<br>
>   build flags used.<br>
<br>
I would steer away from needing extra build time flags to enable these<br>
extensions. If most people don't use these flags then there's a risk of<br>
these bitrotting or getting broken by other patches in the backend or<br>
elsewhere and may add to the support burg<br></blockquote><div><br></div><div>I'd agree that compile-time optionality is best avoided when possible.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would propose a different way of exposing this to the user, exposing<br>
these extensions through the ISA string, but require that an explicit<br>
version number is provided when requesting the extension using the<br>
standard syntax. For example, bitmanip currently sits at version 0.92,<br>
so I would have clang accept for example -march=rv32ib0p92, but error on<br>
-march=rv32ib since it is not yet ratified</blockquote><div><br></div><div>That march flag doesn't scream out to me "Warning! You're using an experimental extension which will probably be changed incompatibly in the next release!" like an explicit command-line flag could do.</div><div><br></div><div>One way to resolve this would be to require _both_ -- you must specify your ISA options with explicit versions in the ISA string, but, doing so would print an error without a separate flag also being enabled, e.g. "error: ISA extension b0p92 is an experimental extension, and support may be removed in future LLVM releases. Pass -mallow-experimental-riscv-isa-extensions to enable."</div><div><br></div><div><br></div></div></div>