On Thu, Oct 9, 2014 at 12:33 PM, Marc Glisse <marc.gli...@inria.fr> 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 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) > https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02328.html > > 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. 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 approach. 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 say). Please also note that this is quite big project. There are plenty of intrinsics and I for one don't want another partial transition ... TL/DR: If there are benefits, no regressions and you think you'll finish the transition, let's go for it. Uros.
