On Wed, Jul 24, 2019 at 5:03 PM Jeff Law <l...@redhat.com> 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.
Huh?
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)
Uros.
