2009-11-17 88 views
3

以下從這個問題:how-do-i-check-if-gcc-is-performing-tail-recursion-optimization,我注意到使用gcc與-fPIC似乎破壞這種優化。我正在創建一個共享庫,但我似乎不需要-fPIC選項。gcc -fPIC似乎與優化標誌糞土

那麼,我的問題是,爲什麼-fPIC更改gcc優化?我是否需要爲任何原因保留-fPIC?

+0

您能提供重現您所描述行爲的方法嗎?這聽起來不對。但是,執行'gcc'的一些內部限制可能會強制禁用PIC模式下的優化... – 2009-11-17 08:03:42

+0

哪個版本的GCC?哪個平臺? '-fPIC'有時會將生成的代碼更改爲'位置獨立代碼'(即PIC),這意味着它可能與「位置相關代碼」不同。你使用什麼選項? – 2009-11-17 08:23:11

+0

啊,在我們的64位服務器gcc sais上需要-fPIC。 – user212658 2009-11-17 08:39:40

回答

4

在不存在細節,諸如目標體系結構和編譯器版本,一個可能的解釋是這樣的:

在依賴於位置的代碼,所述尾遞歸優化基本上重複使用當前堆棧幀,以及替換考慮calljump。語法可以是call function替換爲jmp <small offset of function>

在與位置無關的代碼中,如果指令集允許它(本例爲amd64),則可以將調用寫入call [email protected]。它可以很好地替換爲jmp <small offset of function>@PLT,但這兩個設置確實會發生干擾,也許gcc開發人員沒有考慮在後一種模式下實現尾部呼叫優化。

2

在ia32 linux中,使用fpic意味着你沒有可用於通用目的的ebx,這肯定會影響優化。由於註冊調度壓力,編譯器可能決定拒絕尾部遞歸優化。