This is the mail archive of the
mailing list for the GCC project.
Re: [i386] Replace builtins with vector extensions
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: Marc Glisse <marc dot glisse at inria dot fr>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 9 Oct 2014 08:30:49 -0700
- 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> <alpine dot DEB dot 2 dot 11 dot 1410091352530 dot 8395 at laptop-mg dot saclay dot inria dot fr> <CAFULd4b84VriBCP5DDfHe8Yzto09ZKGK-uPMG51OhF9eBQs_cQ at mail dot gmail dot com>
On Thu, Oct 9, 2014 at 5:57 AM, Uros Bizjak <email@example.com> wrote:
> On Thu, Oct 9, 2014 at 2:28 PM, Marc Glisse <firstname.lastname@example.org> wrote:
>> On Thu, 9 Oct 2014, Uros Bizjak wrote:
>>> On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse <email@example.com> wrote:
>>>> Ping https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html
>>>> (another part of the discussion is around
>>>> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02288.html )
>>>> Most people who commented seem cautiously in favor. The least favorable
>>>> Ulrich who suggested to go with it but keep the old behavior accessible
>>>> 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
>>>> 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?
> OK, let's go in the proposed way, more detailed:
> - we begin with +-*/ of float/double vectors. IMO, this would result
> in a relatively small and easily reviewable patch to iron out the
> details of the approach. Alternatively, we can begin with floats only.
> - commit the patch and wait for the sky to fall down.
> - we play a bit with the compiler to check generated code and corner
> cases (some kind of Q/A) and wait if someone finds a problem (say, a
> couple of weeks).
> - if there are no problems, continue with integer builtins following
> the established approach, otherwise we revert everything and go back
> to the drawing board.
> - repeat the procedure for other builtins.
> I propose to wait a couple of days for possible comments before we get
> the ball rolling.
We should also include some testcases to show code improvement
for each change.