[llvm-dev] [RFC] ASM Goto With Output Constraints
Nick Desaulniers via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 27 11:10:32 PDT 2019
+ CBL mailing list
On Thu, Jun 27, 2019 at 11:08 AM Bill Wendling <isanbard at gmail.com> wrote:
> [Adding the correct cfe-dev mailing list address.]
>
> On Thu, Jun 27, 2019 at 11:06 AM Bill Wendling <isanbard at gmail.com> wrote:
>
>> Now that ASM goto support has landed, Nick Desaulniers and I wrote up a
>> document describing how to expand clang's implementation of ASM goto to
>> support output constraints. The work *should* be straight-forward, but
>> as always will need to be verified to work. Below is a copy of our
>> whitepaper. Please take a look and offer any comments you have.
>>
>> Share and enjoy!
>> -bw
>> Overview
>>
>> Support for asm goto
>> <https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html> with output
>> constraints is a feature that the Linux community is interested in having. Adding
>> this new feature should give Clang a higher profile in the Linux community:
>>
>>
>> -
>>
>> It demonstrates the Clang community's commitment to supporting Linux.
>> -
>>
>> Developers are likely to adopt it on their own, which means they will
>> need to use Clang in some fashion, either as a complete replacement for or
>> in addition to GCC.
>>
>> Current state
>>
>> Clang's implementation of asm goto converts this code:
>>
>> int vogon(unsigned a, unsigned b) {
>> asm goto("poetry %0, %1" : : "r"(a), "r"(b) : : error);
>> return a + b;
>>
>> error:
>> return -1;
>> }
>>
>> into the following LLVM IR:
>>
>> define i32 @vogon(i32 %a, i32 %b) {
>> entry:
>> callbr void asm sideeffect "poetry $0, $1", "r,r,X"
>> (i32 %a, i32 %b, i8* blockaddress(@vogon, %return))
>> to label %asm.fallthrough [label %return]
>>
>> asm.fallthrough:
>> %add = add i32 %b, %a
>> br label %return
>>
>> return:
>> %retval.0 = phi i32 [ %add, %asm.fallthrough ], [ -1, %entry ]
>> ret i32 %retval.0
>> }
>>
>> Our proposal won't change LLVM's current behavior–i.e. a callbr without
>> a return value will act in the same way as the current implementation.
>> Proposal
>>
>> GCC restricts asm goto from having output constraints due to limitations
>> in its internal representation–i.e. GCC's control transfer instructions
>> cannot have outputs. For example:
>>
>> int vogon(int a, int b) {
>> asm goto("poetry %0, %1" : "=r"(a), "=r"(b) : : : error);
>> return a + b;
>>
>> error:
>> return -1;
>> }
>>
>> currently fails to compile in GCC with the following error:
>>
>> <source>: In function 'vogon':
>> <source>:2:29: error: expected ':' before string constant
>> 2 | asm goto("poetry %0, %1" : "=r"(a), "=r"(b) : : : error);
>> | ^~~~~
>> | :
>>
>>
>>
>> ToT Clang matches GCC's behavior:
>>
>> <source>:2:30: error: 'asm goto' cannot have output constraints
>> asm goto("poetry %0, %1" : "=r"(a), "=r"(b) : : : error);
>>
>> However, LLVM doesn't restrict control transfer instructions from having
>> outputs (e.g. the invoke instruction
>> <https://llvm.org/docs/LangRef.html#invoke-instruction>). We propose
>> changing LLVM's callbr instruction
>> <https://llvm.org/docs/LangRef.html#callbr-instruction> to allow return
>> values, similar to how LLVM's implementation of inline assembly (via the
>> call instruction <https://llvm.org/docs/LangRef.html#call-instruction>)
>> allows return values. Since there can potentially be zero to many output
>> constraints, callbr would now return an aggregate which contains an
>> element for each output constraint. These values would then be extracted
>> via extractvalue. With our proposal, the above C example will be
>> converted to LLVM IR like this:
>>
>> define i32 @vogon(i32 %a, i32 %b) {
>> entry:
>> %0 = callbr { i32, i32 } asm sideeffect "poetry $0, $1", "=r,=r,X"
>> (i8* blockaddress(@vogon, %error))
>> to label %asm.fallthrough [label %error]
>>
>>
>> asm.fallthrough:
>> %asmresult.a = extractvalue { i32, i32 } %0, 0
>> %asmresult.b = extractvalue { i32, i32 } %0, 1
>> %result = add i32 %asmresult.a, %asmresult.b
>> ret i32 %result
>>
>> error:
>> ret i32 -1
>> }
>>
>> Note that unlike the invoke instruction, callbr's return values are
>> assumed valid on all branches. The assumption is that the programmer
>> knows what their inline assembly is doing and where its output constraints
>> are valid. If the value isn't valid on a particular branch but is used
>> there anyway, then the result is a poison value. (Also, if a callbr's
>> return values affect a branch, it will be handled similarly to the invoke
>> instruction's implementation.) Here's an example of how this would work:
>>
>> int vogon(int a, int b) {
>> asm goto("poetry %0, %1" : "=r"(a), "=r"(b) : : : error);
>> if (a == 42)
>> return 42 * b;
>> return a + b;
>>
>> error:
>> return b - 42;
>> }
>>
>> generates the following LLVM IR:
>>
>> define i32 @vogon(i32 %a, i32 %b) {
>> entry:
>> %0 = callbr { i32, i32 } asm sideeffect "poetry $0, $1", "=r,=r,X"
>> (i8* blockaddress(@vogon, %error))
>> to label %asm.fallthrough [label %error]
>>
>> asm.fallthrough:
>> %asmresult.a = extractvalue { i32, i32 } %0, 0
>> %tobool = icmp eq i32 %asmresult.a, 42
>> br i1 %tobool, label %if.true, label %if.false
>>
>> if.true:
>> %asmresult.b = extractvalue { i32, i32 } %0, 1
>> %mul = mul i32 42, %asmresult.b
>> ret i32 %mul
>>
>> if.false:
>> %asmresult.a.1 = extractvalue { i32, i32 } %0, 0
>> %asmresult.b.1 = extractvalue { i32, i32 } %0, 1
>> %result = add i32 %asmresult.a.1, %asmresult.b.1
>> ret i32 %result
>>
>> error:
>> %asmresult.b.error = extractvalue { i32, i32 } %0, 1
>> %error.result = sub i32 %asmresult.b.error, 42
>> ret i32 %error.result
>> }
>> Implementation
>>
>> Because LLVM's invoke instruction is a terminating instruction that may
>> have return values, we can use it as a template for callbr's changes.
>> The new functionality lies mostly in modifying Clang's front-end. In
>> particular, we need to do the following:
>>
>>
>> -
>>
>> Remove all error checks restricting asm goto from returning values,
>> and
>> -
>>
>> Generate the extractvalue instructions on callbr's branches.
>>
>>
>> LLVM's middle- and back-ends need to be audited to ensure there are no
>> restrictions on callbr returning a value. We expect all passes to Just
>> Work™ without modifications, but of course will be verified.
>>
>
--
Thanks,
~Nick Desaulniers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/28aed54c/attachment-0001.html>
More information about the llvm-dev
mailing list