網(wǎng)站開發(fā)需要有什么證書搜索引擎排名查詢工具
4.4.3.?X86Subtarget
在X86TargetMachine構(gòu)造函數(shù)的105行調(diào)用了X86Subtarget構(gòu)造函數(shù)來(lái)創(chuàng)建具體的目標(biāo)機(jī)器對(duì)象。
4.4.3.1.?FMV的支持（v7.0）
V7.0將具體目標(biāo)機(jī)器對(duì)象的生成推遲到第一次調(diào)用getSubtarget ()時(shí)才創(chuàng)建。不過(guò)，為了方便起見，我們?cè)谶@里把v7.0的實(shí)現(xiàn)也一起看了。在v7.0里getSubtarget ()是這樣的：
122???? ? template <typename STC> const STC &getSubtarget(const Function &F) const {
123???? ??? return *static_cast<const STC*>(getSubtargetImpl(F));
124???? ? }
目標(biāo)機(jī)器對(duì)象的創(chuàng)建由目標(biāo)機(jī)器的getSubtargetImpl()完成。V7.0的這個(gè)改動(dòng)是為了支持稱為多版本函數(shù)的新特性。關(guān)于這個(gè)新特性，可以參考這個(gè)網(wǎng)址Function multi-versioning in GCC?6 [LWN.net]，下面是它的翻譯（關(guān)于LLVM有這么一篇論文）。
| CPU架構(gòu)隨著演進(jìn)通常會(huì)獲得有趣的新指令，但應(yīng)用程序開發(fā)者通常發(fā)現(xiàn)利用這些指令是困難的。不愿意失去后向兼容是阻礙開發(fā)人員使用更新的計(jì)算架構(gòu)的主要障礙之一。函數(shù)多版本化（function multi-versioning，FMV），首先出現(xiàn)在gcc 4.8，是擁有函數(shù)多個(gè)實(shí)現(xiàn)的方式，每個(gè)實(shí)現(xiàn)使用不同架構(gòu)特定的指令集擴(kuò)展。Gcc 6引入了對(duì)FMV的修改，更容易向應(yīng)用程序代碼引入基于架構(gòu)的優(yōu)化。 盡管gcc與內(nèi)核的新版本嘗試在平臺(tái)面市前公開使用新架構(gòu)特性的工具，但開發(fā)人員難以開始使用這些工具。當(dāng)前，C開發(fā)者有幾個(gè)選擇：
通常使用新架構(gòu)技術(shù)的好處足以壓倒集成的挑戰(zhàn)。例如，打開Intel先進(jìn)向量擴(kuò)展（AVX）會(huì)顯著優(yōu)化數(shù)學(xué)代碼。AVX的第二個(gè)版本（AVX2），在第4代，也稱為Haswell的Intel Core處理器里引入，是一個(gè)選擇。在科學(xué)計(jì)算領(lǐng)域AVX2的好處廣為人知。OpenBLAS庫(kù)使用AVX2給予了像R語(yǔ)言這樣的項(xiàng)目，執(zhí)行上2倍的加速；它也在Python科學(xué)庫(kù)里產(chǎn)生了顯著的提高。這些性能提升是通過(guò)使用256比特指令、浮點(diǎn)融合乘加指令以及gather操作，使每秒浮點(diǎn)操作（FLOPS）加倍，獲得的。 不過(guò)，使用向量擴(kuò)展（VX）技術(shù)意味著大量的開發(fā)、部署以及維護(hù)性工作。維護(hù)多個(gè)版本二進(jìn)制文件的想法（一個(gè)架構(gòu)一個(gè)）阻止開發(fā)者以及發(fā)行版本支持這些特性。 為多個(gè)架構(gòu)優(yōu)化某些關(guān)鍵函數(shù)，當(dāng)運(yùn)行時(shí)二進(jìn)制文件檢測(cè)到CPU能力時(shí)執(zhí)行它們，會(huì)更好嗎？這樣做的一個(gè)特性，FMV，實(shí)際上自gcc 4.8以來(lái)就存在，但僅用于C++。gcc 4.8里的FMV使得開發(fā)者容易指定一個(gè)函數(shù)的多個(gè)版本；每個(gè)針對(duì)特定目標(biāo)機(jī)器指令集優(yōu)化。Gcc負(fù)責(zé)創(chuàng)建執(zhí)行函數(shù)正確版本所需的分發(fā)代碼。 要在C++代碼里使用FMV，用戶要指定函數(shù)的多個(gè)版本。例如，在gcc 4.8 FMV文檔里展示的代碼： ??? __attribute__ ((target ("sse4.2"))) ??? int foo(){ ?????? // foo version for SSE4.2 ?????? return 1; ??? } ??? __attribute__ ((target ("arch=atom"))) ??? int foo(){ ?????? // foo version for the Intel Atom processor ?????? return 2; ??? } ??? int main() { ?????? int (*p)() = &foo; ?????? assert((*p)() == foo()); ?????? return 0; ??? } Target()指示將對(duì)指令集擴(kuò)展（如sse4.2）或指定架構(gòu)（如arch=atom）編譯函數(shù)。 這里，對(duì)每個(gè)函數(shù)，開發(fā)者需要為每個(gè)目標(biāo)創(chuàng)建特殊的函數(shù)與代碼。這將要求代碼里額外的開銷；在FMV程序里代碼行數(shù)的增加，使得它更難以管理與維護(hù)。 幸好，gcc 6解決了這個(gè)問題：它使用單個(gè)屬性來(lái)定義要支持的最小架構(gòu)集，在C及C++代碼里支持FMV。這使得開發(fā)可以利用增強(qiáng)指令的Linux應(yīng)用變得容易，無(wú)需為每個(gè)目標(biāo)復(fù)制函數(shù)。 通過(guò)FMV來(lái)利用AVX的簡(jiǎn)單例子是使用數(shù)組加法（這個(gè)例子是array_addition.c）： ??? #define MAX 1000000 ??? int a[256], b[256], c[256]; ??? __attribute__((target_clones("avx2","arch=atom","default"))) ??? void foo(){ ??????? int i,x; ?????? ?????? for (x=0; x<MAX; x++){ ?????? ??? for (i=0; i<256; i++){ ????????? ??? a[i] = b[i] + c[i]; ?????? ??? } ?????? } ??? } ??? int main() { ??????? foo(); ??????? return 0; ??? } 正如我們可以看到的，使用target_clones()指示支持架構(gòu)的選擇是相當(dāng)簡(jiǎn)單的。開發(fā)者僅需要選擇架構(gòu)或要支持指令集擴(kuò)展的最小集：AVX2、Intel Atom、AMD或幾乎任何gcc從命令行接受的架構(gòu)選項(xiàng)。編譯器將創(chuàng)建函數(shù)面向指定指令集的多個(gè)版本，并在運(yùn)行時(shí)選擇正確的版本。 最終，這個(gè)代碼的object dump有對(duì)每個(gè)架構(gòu)最優(yōu)的匯編指令。例如： 非AVX代碼（Atom）： ??? add??? %eax,%edx AVX: ??? vpaddd 0x0(%rax),%xmm0,%xmm0 AVX2: ??? vpaddd (%r9,%rax,1),%ymm0,%ymm0 注意FMV的新實(shí)現(xiàn)向array_addition.c提供了使用Intel AVX、AVX2甚至Atom平臺(tái)的寄存器與指令的能力。這個(gè)能力增大了應(yīng)用程序可以不出現(xiàn)非法指令錯(cuò)誤運(yùn)行的平臺(tái)的范圍。 在gcc 6以前，告訴編譯器使用Intel AVX2指令將把二進(jìn)制的兼容性限制在Haswell和更新的處理器。通過(guò)FMV里新加的特性，編譯器還可以產(chǎn)生AVX優(yōu)化的代碼；在運(yùn)行時(shí)，將自動(dòng)確保僅使用合適的版本。換而言之，當(dāng)二進(jìn)制運(yùn)行在Haswekk或更新的CPU上時(shí)，將使用Haswell特定的優(yōu)化；當(dāng)同一個(gè)二進(jìn)制在前Haswell世代處理器上運(yùn)行時(shí)，它將回退到使用舊處理器支持的標(biāo)準(zhǔn)指令。 CPUID選擇 在gcc 4.8里，FMV有一個(gè)分發(fā)優(yōu)先級(jí)，而不是一個(gè)CPUID選擇。分發(fā)次序基于目標(biāo)屬性對(duì)每個(gè)函數(shù)版本排序。帶有更先進(jìn)特性的函數(shù)版本有更高的優(yōu)先級(jí)。例如，面向AVX2的版本比面向SSE2的版本優(yōu)先級(jí)更高。 為了保持分發(fā)的低代價(jià)，使用了間接函數(shù)（ifunc）機(jī)制。該機(jī)制是GNU工具鏈的一個(gè)特性，它允許開發(fā)者創(chuàng)建給定函數(shù)的多個(gè)實(shí)現(xiàn)，在運(yùn)行時(shí)使用一個(gè)解析器函數(shù)在其中選擇。在啟動(dòng)早期這個(gè)解析器函數(shù)由動(dòng)態(tài)載入器調(diào)用，決定應(yīng)用程序使用哪個(gè)實(shí)現(xiàn)。一旦做出了實(shí)現(xiàn)選擇，就固定下來(lái)，在這個(gè)過(guò)程的生命期里不變了。 在gcc 6中，解析器檢查CPUID并調(diào)用相應(yīng)的函數(shù)。它對(duì)每個(gè)二進(jìn)制執(zhí)行文件都做一次。因此當(dāng)存在對(duì)FMV函數(shù)的多個(gè)調(diào)用時(shí)，僅第一個(gè)調(diào)用會(huì)執(zhí)行CPUID比較；后續(xù)調(diào)用將通過(guò)一個(gè)指針找到要求的版本。這個(gè)技術(shù)已經(jīng)用于幾乎所有的glibc函數(shù)。例如，glibc對(duì)每個(gè)架構(gòu)都優(yōu)化了memcpy()，因此當(dāng)調(diào)用時(shí)，glibc將調(diào)用恰當(dāng)優(yōu)化的memcpy()。 代碼大小影響 FMV將增加二進(jìn)制代碼的大小，但這個(gè)影響可以最小化。代碼大小的增加依賴于應(yīng)用FMV的函數(shù)有多大，以及要求版本的數(shù)量。如果最初二進(jìn)制代碼大小是C，N是請(qǐng)求的版本數(shù)（包括缺省），R是這些函數(shù)占整個(gè)應(yīng)用程序代碼的比例，新代碼的大小將是： ??? (1 - R) * C + R * C * N 如果一個(gè)應(yīng)用程序最熱代碼占總大小的1%，且應(yīng)用FMV支持三個(gè)架構(gòu)（缺省，sse4.2，avx2），代碼大小總共增加2%。在考慮今天的儲(chǔ)存容量時(shí)，這是相當(dāng)小的影響。但這種影響必須基于部署模型來(lái)考慮。性能、維護(hù)性與增加的二進(jìn)制代碼間存在權(quán)衡，因此對(duì)某種類型的部署FMV可能不是正確的選擇（比如物聯(lián)網(wǎng)設(shè)備）。 結(jié)果 下表展示了在不同處理器上，使用不同gcc標(biāo)記運(yùn)行array_addition.c的執(zhí)行時(shí)間： 執(zhí)行時(shí)間（ms）
FMV版本使用下面的指示： ? ?__attribute__((target_clones("avx2","arch=atom","default"))) SIGILL項(xiàng)表示對(duì)某些組合是非法指令。缺省的CFLAGS（不是特別值得注意），配置作為Clear Linux for Intel Architecture項(xiàng)目部分說(shuō)明。 實(shí)例 今天，越來(lái)越多行業(yè)部門從基于云的科學(xué)計(jì)算中獲益。這些部門包括化工、財(cái)務(wù)以及分析應(yīng)用程序。其中一個(gè)更受歡迎的科學(xué)計(jì)算庫(kù)是用于Python的NumPy庫(kù)。它包括了對(duì)大的、多維數(shù)組與矩陣的支持。它還有用于線性代數(shù)、傅里葉變換以及隨機(jī)數(shù)生成等等的特性。 在一個(gè)諸如NumPy的科學(xué)庫(kù)里使用FMV技術(shù)的好處通常是它得到良好的理解與接受。如果沒有啟用向量化，SIMD寄存器里許多未用的空間浪費(fèi)了。如果啟用向量化，在一條指令里編譯器使用額外的寄存器執(zhí)行更多的操作（比如我們例子里更多整數(shù)加法）。 由于FMV技術(shù)性能的提升（運(yùn)行在帶有AVX2指令的Haswell機(jī)器上），對(duì)科學(xué)計(jì)算內(nèi)容可以到達(dá)3%。我們使用運(yùn)行在1.8GHz的Skylake系統(tǒng)上的OpenBenchmarking.org numpy-1.0.2，使用FMV運(yùn)行時(shí)間是8400秒，而在使用-O3編譯時(shí)是8600秒。 性能提升歸功于從向量化受益的NumPy代碼里的函數(shù)。為了檢測(cè)這些函數(shù)，gcc提供了標(biāo)記-fopt-info-vec。這個(gè)標(biāo)記用于檢測(cè)向量化候選函數(shù)。例如，以這個(gè)標(biāo)記構(gòu)建NumPy將告訴我們文件fftpack.c有可以使用向量化的代碼： ?? ?numpy/fft/fftpack.c:813:7: note: loop peeled for vectorization to enhance alignment 查看NumPy源代碼顯示radfg()函數(shù)，這是NumPy里支持的快速傅里葉變換的一部分，執(zhí)行大量可以使用AVX優(yōu)化的數(shù)組加法。NumPy的補(bǔ)丁還未升級(jí)，但指日可待。 |
250???? const X86Subtarget *
251???? X86TargetMachine::getSubtargetImpl(const Function &F) const {
252???? ? Attribute CPUAttr = F.getFnAttribute("target-cpu");
253???? ? Attribute FSAttr = F.getFnAttribute("target-features");
254????
255???? ? StringRef CPU = !CPUAttr.hasAttribute(Attribute::None)
256???? ????????????????????? ? CPUAttr.getValueAsString()
257???? ????????????????????? : (StringRef)TargetCPU;
258???? ? StringRef FS = !FSAttr.hasAttribute(Attribute::None)
259???? ???????????????????? ? FSAttr.getValueAsString()
260???? ???????????????????? : (StringRef)TargetFS;
261????
262???? ? SmallString<512> Key;
263???? ? Key.reserve(CPU.size() + FS.size());
264???? ? Key += CPU;
265???? ? Key += FS;
266????
267???? ? // FIXME: This is related to the code below to reset the target options,
268???? ? // we need to know whether or not the soft float flag is set on the
269???? ? // function before we can generate a subtarget. We also need to use
270???? ? // it as a key for the subtarget since that can be the only difference
271???? ? // between two functions.
272???? ? bool SoftFloat =
273???? ????? F.getFnAttribute("use-soft-float").getValueAsString() == "true";
274???? ? // If the soft float attribute is set on the function turn on the soft float
275???? ? // subtarget feature.
276???? ? if (SoftFloat)
277???? ??? Key += FS.empty() ? "+soft-float" : ",+soft-float";
278????
279???? ? // Keep track of the key width after all features are added so we can extract
280???? ? // the feature string out later.
281???? ? unsigned CPUFSWidth = Key.size();
282????
283???? ? // Extract prefer-vector-width attribute.
284???? ? unsigned PreferVectorWidthOverride = 0;
285???? ? if (F.hasFnAttribute("prefer-vector-width")) {
286???? ??? StringRef Val = F.getFnAttribute("prefer-vector-width").getValueAsString();
287???? ??? unsigned Width;
288???? ??? if (!Val.getAsInteger(0, Width)) {
289???? ????? Key += ",prefer-vector-width=";
290???? ????? Key += Val;
291???? ????? PreferVectorWidthOverride = Width;
292???? ??? }
293???? ? }
294????
295???? ? // Extract required-vector-width attribute.
296???? ? unsigned RequiredVectorWidth = UINT32_MAX;
297???? ? if (F.hasFnAttribute("required-vector-width")) {
298???? ??? StringRef Val = F.getFnAttribute("required-vector-width").getValueAsString();
299???? ??? unsigned Width;
300???? ??? if (!Val.getAsInteger(0, Width)) {
301???? ????? Key += ",required-vector-width=";
302???? ????? Key += Val;
303???? ????? RequiredVectorWidth = Width;
304???? ??? }
305???? ? }
306????
307???? ? // Extracted here so that we make sure there is backing for the StringRef. If
308???? ? // we assigned earlier, its possible the SmallString reallocated leaving a
309???? ? // dangling StringRef.
310???? ? FS = Key.slice(CPU.size(), CPUFSWidth);
311????
312???? ? auto &I = SubtargetMap[Key];
313???? ? if (!I) {
314???? ?? ?// This needs to be done before we create a new subtarget since any
315???? ??? // creation will depend on the TM and the code generation flags on the
316???? ??? // function that reside in TargetOptions.
317???? ??? resetTargetOptions(F);
318???? ??? I = llvm::make_unique<X86Subtarget>(TargetTriple, CPU, FS, *this,
319???? ??????????????????????????????????????? Options.StackAlignmentOverride,
320???? ??????????????????????????????????????? PreferVectorWidthOverride,
321???? ??????????????? ????????????????????????RequiredVectorWidth);
322???? ? }
323???? ? return I.get();
324???? }
MFV需要多個(gè)目標(biāo)機(jī)器可用，因此現(xiàn)在使用容器SubtargetMap（類型mutable StringMap<std:: unique_ptr<X86Subtarget>>）來(lái)保存多個(gè)X86Subtarget實(shí)例，鍵值是描述目標(biāo)CPU以及各方面特性的字符串，這個(gè)字符串確保唯一。
317行的resetTargetOptions()根據(jù)當(dāng)前函數(shù)的屬性改寫由InitTargetOptionsFromCodeGenFlags()等根據(jù)編譯命令行設(shè)置的屬性。
在318行創(chuàng)建X86Subtarget實(shí)例。
289???? X86Subtarget::X86Subtarget(const Triple &TT, const std::string &CPU,
290???? ?????????????????????????? const std::string &FS, const X86TargetMachine &TM,
291???? ?????????????????????????? unsigned StackAlignOverride)
292???? ??? : X86GenSubtargetInfo(TT, CPU, FS), X86ProcFamily(Others),
293???? ????? PICStyle(PICStyles::None), TargetTriple(TT),
294???? ????? StackAlignOverride(StackAlignOverride),
295???? ????? In64BitMode(TargetTriple.getArch() == Triple::x86_64),
296???? ????? In32BitMode(TargetTriple.getArch() == Triple::x86 &&
297???? ????????????????? TargetTriple.getEnvironment() != Triple::CODE16),
298???? ????? In16BitMode(TargetTriple.getArch() == Triple::x86 &&
299???? ????????????????? TargetTriple.getEnvironment() == Triple::CODE16),
300???? ????? TSInfo(), InstrInfo(initializeSubtargetDependencies(CPU, FS)),
301???? ????? TLInfo(TM, *this), FrameLowering(*this, getStackAlignment()) {
302???? ? // Determine the PICStyle based on the target selected.
303???? ? if (TM.getRelocationModel() == Reloc::Static !isPositionIndependent()) {
304???? ??? // Unless we're in PIC or DynamicNoPIC mode, set the PIC style to None.
305???? ??? setPICStyle(PICStyles::None);
306???? ? } else if (is64Bit()) {
307???? ??? // PIC in 64 bit mode is always rip-rel.
308???? ??? setPICStyle(PICStyles::RIPRel);
309???? ? } else if (isTargetCOFF()) {
310???? ??? setPICStyle(PICStyles::None);
311???? ? } else if (isTargetDarwin()) {
312???? ??? if (TM.getRelocationModel() == Reloc::PIC_)?????????????????????????????????????????????????????????????????????? ? v7.0刪除
313???? ????? setPICStyle(PICStyles::StubPIC);
314???? ??? else {
315???? ????? assert(TM.getRelocationModel() == Reloc::DynamicNoPIC);
316???? ????? setPICStyle(PICStyles::StubDynamicNoPIC);
317???? ??? }
318???? ? } else if (isTargetELF()) {
319???? ??? setPICStyle(PICStyles::GOT);
320???? ? }
? CallLoweringInfo.reset(new X86CallLowering(*getTargetLowering()));?????????????????????????? ? v7.0增加
? Legalizer.reset(new X86LegalizerInfo(*this, TM));
? auto *RBI = new X86RegisterBankInfo(*getRegisterInfo());
? RegBankInfo.reset(RBI);
? InstSelector.reset(createX86InstructionSelector(TM, *this, *RBI));
321???? }
基類X86GenSubtargetInfo的構(gòu)造函數(shù)是TableGen生成的，前面我們已經(jīng)看到，它將MC層的一組指針指向X86目標(biāo)機(jī)器特定的參數(shù)。300行的成員TSInfo的類型是X86SelectionDAGInfo，目標(biāo)機(jī)器通過(guò)它可以提供對(duì)memcpy、memmove、memset、memcmp、memchr、strcpy、strcmp、strlen，這些操作的專屬處理代碼（v7.0刪除這個(gè)調(diào)用）。
303行的isPositionIndependent()檢查使用的重定位模型是否為Reloc::PIC_，這些重定位模型用于動(dòng)態(tài)庫(kù)的生成。V7.0簡(jiǎn)化為這幾種：StubPIC（i386-darwin的pic），GOT（全局對(duì)象表，32位elf的pic），RIPRel（相對(duì)RIP，64位elf的pic），None（沒有使用pic）。位置無(wú)關(guān)代碼參考有關(guān)資料（如《C++高級(jí)編譯》）。