This is the mail archive of the
mailing list for the GCC project.
Re: [i386] Replace builtins with vector extensions
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 9 Oct 2014 14:28:30 +0200 (CEST)
- Subject: Re: [i386] Replace builtins with vector extensions
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1404112137530 dot 19663 at stedding dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 10 dot 1404281322180 dot 3620 at laptop-mg dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 10 dot 1405171529460 dot 3642 at laptop-mg dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 10 dot 1406281230560 dot 9234 at laptop-mg dot saclay dot inria dot fr> <20140703101605 dot GA12583 at msticlxl57 dot ims dot intel dot com> <alpine dot DEB dot 2 dot 10 dot 1407031613450 dot 2526 at laptop-mg dot saclay dot inria dot fr> <20140708111402 dot GB14139 at msticlxl57 dot ims dot intel dot com> <alpine dot DEB dot 2 dot 11 dot 1407261739190 dot 19562 at stedding dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 11 dot 1410091158301 dot 1624 at laptop-mg dot saclay dot inria dot fr> <CAFULd4YPKPhDSNdVNDn0P2CgZk-PUkecM3pS4iYJ1SB=gFZ0MQ at mail dot gmail dot com>
On Thu, 9 Oct 2014, Uros Bizjak wrote:
On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse <email@example.com> wrote:
(another part of the discussion is around
Most people who commented seem cautiously in favor. The least favorable was
Ulrich who suggested to go with it but keep the old behavior accessible if
the user defines some macro (which imho would lose a large part of the
simplification benefits of the patch)
If this is accepted, I will gladly prepare patches removing the unused
builtins and extending this to a few more operations (integer vectors in
particular). If this is not the direction we want to go, I'd like to hear it
clearly so I can move on...
Well, I'm undecided.
First, thanks for answering, it helps me a lot to know what others think.
The current approach is proven to work OK, there is no bugs reported
in this area and the performance is apparently OK. There should be
clear benefits in order to change something that "ain't broken", and
at least some proof that we won't regress in this area with the new
There are quite a few enhancement PRs asking for more performance, but
indeed no (or very few) complaints about correctness or about gcc turning
their code into something worse than what they wrote, which I completely
agree weighs more.
On the other hand, if the new approach opens new optimization
opportunities (without regression!), I'm in favor of it, including the
fact that new code won't produce equivalent assembly - as long as
functionality of the optimized asm stays the same (obviously, I'd
Please also note that this is quite big project. There are plenty of
intrinsics and I for one don't want another partial transition ...
That might be an issueÂ: this transition is partial by nature. Many
intrinsics cannot (easily) be expressed in GIMPLE, and among those that
can be represented, we only want to change those for which we are
confident that we will not regress the quality of the code. From the
reactions, I would assume that we want to be quite conservative at the
beginning, and maybe we can reconsider some other intrinsics later.
The best I can offer is consistency: if addition of v2df is changed,
addition of v4df is changed as well (and say any +-*/ of float/double
vectors of any supported size). Another block would be +-*/% for integer
vectors. And construction / access (most construction is already
builtin-free). And remove the unused builtins in the same patch that makes
them unused. If you don't like those blocks, I can write one mega-patch
that does all these, if we roughly agree on the list beforehand, so it
goes in all at once.
Would that be good enough?
TL/DR: If there are benefits, no regressions and you think you'll
finish the transition, let's go for it.