public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Harald van Dijk <harald@gigawatt.nl>
To: Florian Weimer <fweimer@redhat.com>, gcc-help@gcc.gnu.org
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: Inline assembly and value extensions
Date: Mon, 5 Oct 2020 14:39:52 +0100	[thread overview]
Message-ID: <4f53960b-f5ed-e61f-fdc6-d6ac7b070e24@gigawatt.nl> (raw)
In-Reply-To: <87ft6sx0lt.fsf@oldenburg2.str.redhat.com>

On 05/10/2020 14:29, Florian Weimer wrote:
> * Harald van Dijk via Gcc-help:
> 
>> In the x32 ABI, pointers do not have a single mode. They are SImode,
>> except when passed as parameters or returned, in which case they are
>> DImode (see the ix86_promote_function_mode function I mentioned). This
>> is really the source of the problems.
> 
> I think that GCC cannot optimize away unecessary sign and zero
> extensions is also a contributing factor, no?

Hmm, yes, that is a good point too. An ugly way to try to inform GCC 
that the extension is unnecessary would be

   void *return_a_pointer(void) {
     unsigned long long result;
     asm("movl $0x11223344, %%eax" : "=a"(result));
     if (result & 0xFFFFFFFF00000000ULL)
       __builtin_unreachable();
     return (void *)result;
   }

This is not something I would want to have to write explicitly, but it 
does not help anyway at the moment, even in this case GCC emits the 
extra extension: <https://godbolt.org/z/vPb1Mr>. I think here the code 
does give enough information to GCC that it could in theory optimize it 
away.

(clang does not emit the extra extension, but that is because LLVM 
implements this ABI incorrectly, so not a fair comparison. I hope to be 
able to submit a patch to them for that at some later time.)

      reply	other threads:[~2020-10-05 13:39 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
2020-10-05 13:26     ` Harald van Dijk
2020-10-05 13:29       ` Florian Weimer
2020-10-05 13:39         ` Harald van Dijk [this message]

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=4f53960b-f5ed-e61f-fdc6-d6ac7b070e24@gigawatt.nl \
    --to=harald@gigawatt.nl \
    --cc=fweimer@redhat.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=segher@kernel.crashing.org \
    /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).