From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.gigawatt.nl (mail.gigawatt.nl [IPv6:2001:41d0:801:2000::19e9]) by sourceware.org (Postfix) with ESMTPS id 189BD387087D for ; Sat, 3 Oct 2020 20:42:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 189BD387087D Received: from [192.168.1.6] (hvdijk.plus.com [81.174.157.28]) by mail.gigawatt.nl (Postfix) with ESMTPSA id 948A673A for ; Sat, 3 Oct 2020 22:42:44 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.gigawatt.nl 948A673A Subject: Re: Inline assembly and value extensions From: Harald van Dijk To: gcc-help@gcc.gnu.org References: <8985cc81-573c-b011-4e02-aa9829524133@gigawatt.nl> Message-ID: <3c338ceb-1dfa-5c15-8295-5b5a7dd4bad7@gigawatt.nl> Date: Sat, 3 Oct 2020 21:42:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:81.0) Gecko/20100101 Thunderbird/81.0 MIME-Version: 1.0 In-Reply-To: <8985cc81-573c-b011-4e02-aa9829524133@gigawatt.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 20:42:48 -0000 On 22/08/2020 16:30, Harald van Dijk wrote: > Hi, > > I am trying to port some x86-64 inline assembly to work properly for the > x32 ABI and I am running into a small problem. The x32 ABI specifies > that pointers are passed and returned zero-extended to 64 bits. When a > pointer variable is defined by an inline assembly statement and then > returned by a function, I do not see a way to inform GCC that the result > is already zero-extended, that GCC does not need to zero-extend it again. > > A silly example: > >  void *return_a_pointer(void) { >    void *result; >    asm("movl $0x11223344, %%eax" : "=a"(result)); >    return result; >  } > > This function gets an extra "movl %eax, %eax" between the hand-written > movl and the generated ret, which can be seen online at > . This extra movl is there to ensure the > high bits of %rax are zero, but the initial movl already achieves that. > How can I inform GCC that it does not need to emit that extra movl? > > Likewise, is there an easy way to provide an inline assembly statement > with a zero-extended pointer input? This one I am able to work around, > as it is possible to instead of passing in a pointer value p, pass in an > integer value (uint64_t)(uint32_t)p, but the workaround is kind of hard > to read and I would like to avoid that if possible. > > I looked the documentation for either relevant inline assembly > constraints or relevant variable / type attributes, but was unable to > find any. The most promising search result was the mode attribute, I was > hoping it might be possible to give result a mode(DI) attribute, but the > compiler rejects that. I have now found that forcing a different mode appears to be exactly how the zero-extension of arguments and return values is implemented: that is what ix86_promote_function_mode does. The fact that this is not an option through variable attributes or inline assembly constraints looks like an unfortunate limitation of the inline assembly functionality, there is currently just no way to do what I am after. I very much hope to be proved wrong, but will try to just pick a workaround that does not look too bad. > Is there another approach that I can use instead? > > Cheers, > Harald van Dijk