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.
next prev 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).