public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Harald van Dijk <harald@gigawatt.nl>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Inline assembly and value extensions
Date: Mon, 5 Oct 2020 07:53:28 -0500	[thread overview]
Message-ID: <20201005125328.GA2672@gate.crashing.org> (raw)
In-Reply-To: <3c338ceb-1dfa-5c15-8295-5b5a7dd4bad7@gigawatt.nl>

On Sat, Oct 03, 2020 at 09:42:40PM +0100, Harald van Dijk via Gcc-help wrote:
> On 22/08/2020 16:30, Harald van Dijk wrote:
> >This function gets an extra "movl %eax, %eax" between the hand-written 
> >movl and the generated ret, which can be seen online at 
> ><https://godbolt.org/z/T8bGPo>. 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?

If your asm returns a 32-bit value, then GCC will not know what is in
the top 32 bits of the 64-bit register.

> >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.

You can use much less chatty names for those very basic types (like u64
and u32), that makes it more readable.  Hiding what you do will not make
it more readable, that is just obfuscation, so using macros is not such
a good idea.  Inline asm is hard enough when you can see all there is
right in front of your eyes.

> >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.

Constraints just say which register (or memory addressed how, or what
kind of constnt).  The normal way to say something should have a certain
mode is by giving it a corresponding type in C (so SImode is "int" in C,
and DImode is "long long"; "long" is either, it depends on your ABI;
"u64" and "u32" should always be clear ;-) )

> 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?

You use a 64-bit expression (or preferably even a 64-bit variable).  The
same is true for outputs from the asm.

One way of making the code easier to read is to actually use 64-bit
variables for all these things in the asm, and then assign them from and
to the 32-bit things.

  int x;
  char *p;
  u64 xx = x;
  u64 pp = (u64)p;
  asm("smth %0,%1" : "+r"(pp), "+r"(xx));
  p = (char *)pp;
  x = xx;


Segher

  reply	other threads:[~2020-10-05 12:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-22 15:30 Harald van Dijk
2020-10-03 20:42 ` Harald van Dijk
2020-10-05 12:53   ` Segher Boessenkool [this message]
2020-10-05 13:26     ` Harald van Dijk
2020-10-05 13:29       ` Florian Weimer
2020-10-05 13:39         ` Harald van Dijk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201005125328.GA2672@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=gcc-help@gcc.gnu.org \
    --cc=harald@gigawatt.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).