--- Comment #8 from UroŇ° Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Biener from comment #7)

> So it seems V2DFmode is available but discouraged via the above hook when
> tuning for atom.
> Indeed:
> static machine_mode
> ix86_preferred_simd_mode (machine_mode mode)
> {
> ...
>     case DFmode:
>         return word_mode;

This part should be OK, the hook documentation says:

          (machine_mode MODE)
     This hook should return the preferred mode for vectorizing scalar
     mode MODE.  The default is equal to 'word_mode', because the
     vectorizer can do some transformations even in absence of
     specialized SIMD hardware.

IIUC, word_mode should be returned for unsupported scalar modes.

> but targetm.vector_mode_supported_p happily returns true for V2DFmode.

Yes, also following the documentation:

 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE)
     Define this to return nonzero if the port is prepared to handle
     insns involving vector mode MODE.  At the very least, it must have
     move patterns for this mode.

We *do* have V2DF move patterns.

> This means the above is _not_ a good way to achieve what it tries to
> (make the vectorizer not use V2DFmode).  A more proper way would be to
> handle this in ix86_add_stmt_cost, increasing the cost for double type
> vectorization.
> Nevertheless the vectorizer shouldn't ICE on this inconsistency, I'll see
> what it takes to "fix" it on the vectorizer side.

Please note that we have similar situation with TARGET_PREFER_AVX128, the
difference is that we still vectorize with narrower vector mode, whereas
V2DFmode falls back to a word_mode.

Reply via email to