public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "euloanty at live dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/97437] builtins subcarry and addcarry still not generate the right code. Not get optimized to immediate value
Date: Thu, 15 Oct 2020 13:47:27 +0000	[thread overview]
Message-ID: <bug-97437-4-QLlN5Q05QS@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-97437-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97437

--- Comment #4 from fdlbxtqi <euloanty at live dot com> ---
(In reply to Jakub Jelinek from comment #1)
> I don't see anything undesirable on that.  The 0 aka %rax is used in 7
> different instructions later on besides the move, so either we just clear
> %ecx (can't use xorl for that as the flags register needs to be live), or
> clear %eax and copy to %ecx (3 bytes more), but then gain 7 bytes back
> because we don't really use an immediate form.

Hello Jakub.

std::uint64_t a{};//must assign as 0 or it is UB.
sub_borrow(borrow,a,a,a);

sbbq %any_new_rigster,%any_new_rigster

means
std::uint64_t a;
if(borrow)
    a=std::numeric_limits<std::uint64_t>::max();
else
    a=0;

but faster, use less instructions and without any branch (to prevent side
channel attack)

And all those 

sub_borrow(borrow,f[2],zero,f[3]);

So, you do not need to use %rax register for the calculations at all. %rax
would just be used for RVO.

clang does not do the right thing either if I do not write

constexpr unsigned_type zero{};

to tell compiler it is zero, it does not know that either.

I think because _addcarry_, _subborrow_ was not frequently used in GCC, it
lacks many optimizations points here. That is probably why GMP, OpenSSL etc,
they frequently rewrote assemblies for doing the stuff since the compiler does
not guarantee the instructions that got generated as optimal. I know this is
probably the cost of any abstraction, particularly here I combine the usage of
OOP, concepts, templates, if constexpr, constant_evaluated(), RVO and intrinsic
together. Probably interfere with the compiler optimizations. it does not
guarantee to generate the assembly that is optimal compared to assembly.

  parent reply	other threads:[~2020-10-15 13:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15  8:28 [Bug rtl-optimization/97437] New: " euloanty at live dot com
2020-10-15 11:20 ` [Bug target/97437] " jakub at gcc dot gnu.org
2020-10-15 12:29 ` jakub at gcc dot gnu.org
2020-10-15 12:52 ` jakub at gcc dot gnu.org
2020-10-15 13:47 ` euloanty at live dot com [this message]
2020-10-15 13:57 ` segher at gcc dot gnu.org
2020-10-15 13:59 ` segher at gcc dot gnu.org
2020-10-15 14:00 ` jakub at gcc dot gnu.org
2020-10-15 15:14 ` segher at gcc dot gnu.org
2020-10-15 15:20 ` jakub at gcc dot gnu.org
2020-10-15 17:00 ` segher at gcc dot gnu.org

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=bug-97437-4-QLlN5Q05QS@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).