This is the mail archive of the gcc@gcc.gnu.org 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: i386/x86-64 UNSPEC_NOP usage


Perhaps related to that, there seem to be even more fundamental problems
with MMX instruction usage. Due to the programming model (which requires
(a) not mixing FP and MMX instructions and (b) [f]emms after sequences
of MMX operations) it seems rather questionable whether it is
appropriate for the compiler to emit MMX code without being asked to
(i.e. through intrinsics). Possibly, the mentioned UNSPEC_NOP is
targeted at suppressing such, but if so, then quite a few more insns
require this construct to be added. Namely, when compiling code using
'SSE' vector types (i.e. V4SI) with -mmmx (but not -msse) the compiler
silently generates pairs of MMX instructions (rather than sequences of
integer ones), but of course fails to generate emms in the epilogue(s).
I can only see two valid models here: Either the compiler doesn't
generate MMX code at all unless explicitly asked to through intrinsics
(in which case it is the programmer's responsibility to also invoke the
emms intrinsic at the appropriate place(s), but it would of course be
more than appropriate for the compiler to emit a warning if it detects a
violation of the model), or it fully knows about the programming model
(i.e. it sufficiently separates FP and MMX code, including the required
use of [f]emms).
Regarding the original question this would, as far as I understand that
for the former case all MMX insns would have to both get an mmx_ prefix
(to make them invisible to the default insn selection) and the
UNSPEC_NOP framing (to hide the operations from the optimizer), while in
the latter case all mmx_ prefixes and UNSPEC_NOP uses could (should) go
away.

Obviously, for SSE such a problem doesn't exist since its register
space is distinct. Special considerations might be needed for those
cases where conversions happen between %xmm and %mm registers.

Jan

>>> original text

Would you be able to explain what UNSPEC_NOP is really good for. Since
it's being used only for very few insns, it would seem that if it's
required at all the problem might lie somewhere else. While I'm trying
to fix various inconsistencies in the MMX/SSE support, I'd like to also
do away with some of the superfluous builtins. While for SSE2 the
logicals don't have this set (and thus can be made, by removing their
sse_ prefixes, generic insns that can be recognized also for operations
on vector operands without using builtin functions), the MMX logicals
have this set and I would thus be unsure whether this conflicts in some
way with other expectations the compiler may have elsewhere,
consequently putting under question whether the mmx_ prefixes can also
safely be removed.

Thanks, Jan


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