This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

On Wed, Jul 24, 2019 at 5:03 PM Jeff Law <> wrote:

> > Clearly this approach will run into register allocation issues
> > but it looks cleaner than writing yet another STV-like pass
> > (STV itself is quite awkwardly structured so I refrain from
> > touching it...).
> >
> > Anyway - comments?  It seems to me that MMX-in-SSE does
> > something very similar.
> >
> > Bootstrapped on x86_64-unknown-linux-gnu, previous testing
> > revealed some issue.  Forgot that *add<mode>_1 also handles
> > DImode..., fixed below, re-testing in progress.
> Certainly simpler than most of the options and seems effective.
> FWIW, I think all the STV code is still disabled and has been for
> several releases.  One could make an argument it should get dropped.  If
> someone wants to make something like STV work, they can try again and
> hopefully learn from the problems with the first implementation.


STV code is *enabled by default* on 32bit SSE2 targets, and works
surprisingly well (*) for DImode arithmetic, logic and constant shift
operations. Even 32bit multilib on x86_64 is built with STV.

I am indeed surprised that the perception of the developers is that
STV doesn't work. Maybe I'm missing something obvious here?

(*) The infrastructure includes:
  - cost analysis of the whole STV chain, including moves from integer
registers, loading and storing DImode values
  - preloading of arguments into vector registers to avoid duplicate
int-vec moves
  - different strategies to move arguments between int and vector
registers (e.g. respects TARGET_INTER_UNIT_MOVES_{TO,FROM}_VEC flag)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]