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


Jan Beulich wrote:
Perhaps related to that, there seem to be even more fundamental problems
with MMX instruction usage. Due to the programming model

Yes.


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).

Sounds right to me.


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.

The latter case is probably hard to get right, and to get efficient code. This requires the compiler to keep track of mode switching for the FP/MMX register bank, which is an unusual thing for the compiler to do. The only case I can think of offhand is the SH4 FPU which has to mode switch between SFmode and DFmode operations. There is a lot of complexity in the SH port to deal with this. It is probably not a good idea to try to do the same thing in the i386 port for the MMX instructions. I doubt that the maintenance hassles will be worth the performance benefit, especially since SSE is better, and most people probably already have it. So I suspect that the former is a better solution. You can try writing a patch for it, or you can try submitting a bugzilla bug report so we don't forget about the problem.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com



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