This file defines the pass that looks through the machine instructions late in the compilation, and finds byte or word instructions that can be profitably replaced with 32 bit instructions that give equivalent results for the bits of the results that are used. More...

#include "X86.h"
#include "X86InstrInfo.h"
#include "X86Subtarget.h"
#include "llvm/ADT/Statistic.h"
#include "llvm/CodeGen/LivePhysRegs.h"
#include "llvm/CodeGen/MachineFunctionPass.h"
#include "llvm/CodeGen/MachineInstrBuilder.h"
#include "llvm/CodeGen/MachineLoopInfo.h"
#include "llvm/CodeGen/MachineRegisterInfo.h"
#include "llvm/CodeGen/Passes.h"
#include "llvm/CodeGen/TargetInstrInfo.h"
#include "llvm/Support/Debug.h"
#include "llvm/Support/raw_ostream.h"

Include dependency graph for X86FixupBWInsts.cpp:

Go to the source code of this file.

Macros
#define	FIXUPBW_DESC "X86 Byte/Word Instruction Fixup"

#define	FIXUPBW_NAME "x86-fixup-bw-insts"

#define	DEBUG_TYPE FIXUPBW_NAME

Variables
static cl::opt< bool >	FixupBWInsts ("fixup-byte-word-insts", cl::desc("Change byte and word instructions to larger sizes"), cl::init(true), cl::Hidden)

Detailed Description

This file defines the pass that looks through the machine instructions late in the compilation, and finds byte or word instructions that can be profitably replaced with 32 bit instructions that give equivalent results for the bits of the results that are used.

There are two possible reasons to do this.

One reason is to avoid false-dependences on the upper portions of the registers. Only instructions that have a destination register which is not in any of the source registers can be affected by this. Any instruction where one of the source registers is also the destination register is unaffected, because it has a true dependence on the source register already. So, this consideration primarily affects load instructions and register-to-register moves. It would seem like cmov(s) would also be affected, but because of the way cmov is really implemented by most machines as reading both the destination and and source registers, and then "merging" the two based on a condition, it really already should be considered as having a true dependence on the destination register as well.

The other reason to do this is for potential code size savings. Word operations need an extra override byte compared to their 32 bit versions. So this can convert many word operations to their larger size, saving a byte in encoding. This could introduce partial register dependences where none existed however. As an example take: orw ax, $0x1000 addw ax, $3 now if this were to get transformed into orw ax, $1000 addl eax, $3 because the addl encodes shorter than the addw, this would introduce a use of a register that was only partially written earlier. On older Intel processors this can be quite a performance penalty, so this should probably only be done when it can be proven that a new partial dependence wouldn't be created, or when your know a newer processor is being targeted, or when optimizing for minimum code size.

Definition in file X86FixupBWInsts.cpp.

Macro Definition Documentation

◆ DEBUG_TYPE

#define DEBUG_TYPE FIXUPBW_NAME

Definition at line 66 of file X86FixupBWInsts.cpp.

◆ FIXUPBW_DESC

#define FIXUPBW_DESC "X86 Byte/Word Instruction Fixup"

Definition at line 63 of file X86FixupBWInsts.cpp.

◆ FIXUPBW_NAME

#define FIXUPBW_NAME "x86-fixup-bw-insts"

Definition at line 64 of file X86FixupBWInsts.cpp.

Variable Documentation

◆ FixupBWInsts

cl::opt<bool> FixupBWInsts("fixup-byte-word-insts", cl::desc("Change byte and word instructions to larger sizes"), cl::init(true), cl::Hidden)

static

Referenced by llvm::createX86FixupBWInsts().

Macros