LLVM 的基本型別是如何設計的

時間 2021-05-09 16:53:54

1樓:陸明非

一開始是有sign/unsigned的,後來去了,資訊放在opcode上,opcode有signed和unsigned,這樣基本上和硬體一致了.

2樓:saturnman

我前一段時間略翻了一遍llvm的ref,型別這一塊屬於抽象和具體硬體平衡的一種結果。基本上參考了過去幾十年主流處理器架構支援的基本型別再加上一點點抽象和約束,一些特意的硬體架構資料型別沒有包含在基礎型別裡面,當然特異的型別基本都是繫結了一組特定的功能上,這些東西在不同架構上採用intrinsic函式層去包裝了。甚至還有英特爾把很複雜的功能包裝成intrinsic函式和llvm團隊成員爭執的趣事。

3樓:悲路

LLVM 2.0之前是有的,但對現代的LLVM來說更關心資料的長度而不是現代程式語言意義上的型別。這個enhancement request的解釋是加入整數符號會讓IR大小增加,並讓一些優化不可用。

4樓:zephyr z

型別主要是關注儲存位寬

具體資料的含義由指令來決定

這個和底層機器指令更貼近。load / store 的時候並不關心有符號/無符號,對吧

5樓:

我之前研究的時候也遇到了這個問題,我的理解是對於計算機來說,整數不管是signed還是unsigned,事實上都是一堆二進位制的bit嘛,signed與否只取決於你怎麼看他。所以LLVM裡型別只有位數之分,但當你想要操作他的時候,有些操作不關心符號的就只有乙個操作,而關心符號的就會有對應於signed和unsigned的兩種版本,至於用哪個,只能在前端自己維護型別資訊,生成IR的時候根據型別資訊選擇適合的操作。

據說這樣設計還能更便於優化,這一部分不太了解不置可否。

6樓:dshe

對底層來說signed int和unsigned int的區別很小,只有某些指令會有影響,很多處理器的彙編就是這樣的。

LLVM裡面就是通過不同的指令來區分,譬如sdiv和udiv,還有icmp不同的condition code等。另外還有nsw和nuw這種flag來標記signed和unsigned overflow。

7樓:開源醬

signed bit / bool 是什麼鬼。。。

你就一位哪來的 sign。。。

不區分 signed / unsigned 因為二進位制數你可以按照你的需要隨便解釋,需要 signed 的時候你就把最高位當成是 sign 位然後算補碼唄。。。

好處當然就是編譯方便,CPU 又不會做有符號運算(

javascript中,基本型別的變數的賦值語句會在記憶體中產生兩個副本嗎?

唐靜鑫 JS的基本型別是存在棧中的,而且每個基本型別都是單獨儲存在記憶體的不同位址中。所以在日常的開發中,你會發現基本型別的賦值並不會相互影響。 賀師俊 只要保證符合 ECMAScript 規範規定的語義,記憶體裡是幾份是無所謂的。而且就算是兩份,通常你也看不出來。在現代JS引擎中,對字串有各種優化...

java基本型別是原子性的,多執行緒時是否還需要宣告volatile來保證可見性?

哲學家888 這種問題,你肯定會得到互相矛盾的答案,不知道該信哪個。最正確的答案在JVM specification 裡,自己去看。當然這題還算簡單,所以你也可以信一下我。Volatile 確實主要是保證可見性,但它也確實額外有原子性的保證。Long 和 double 的讀寫在JVM specifi...

java的基本型別的成員變數在棧還是堆?

Intopass 區域性變數在stack中,包括基本型別變數和引用。成員變數在heap中,包括基本型別變數和引用。引用中儲存的是指向head的位址。說到引用型別時,要把引用自身和heap中的物件區分開來。你完全可以宣告乙個引用賦值為null,那麼就不指向heap中的物件了。 愛諳夜令 先說結論,放在...