作者查詢 / Lipraxde

總覽項目：發文 | 留言 | 暱稱

作者 Lipraxde 在 PTT [ CompilerDev ] 看板的留言(推文), 共148則

限定看板：CompilerDev

看板排序：

首頁

尾頁

[問題] 關於 Google SWE Silicon Team Match

[ CompilerDev ]7 留言, 推噓總分: +1

作者: hkhs7821 - 發表於 2021/12/18 23:59(4年前)

1^F→Lipraxde: 這個寫要四年經驗耶12/19 13:22

[問題] 取得llvm IR RAW等等資料相依

[ CompilerDev ]36 留言, 推噓總分: +1

作者: shane87123 - 發表於 2021/12/01 15:27(4年前)

5^F→Lipraxde: LLVM 最為一個 SSA form 的 IR，value 「只能被賦值一12/01 19:45

6^F→Lipraxde: 次」，def-use chain 就是你要找的「value 的關係」了12/01 19:45

7^F→Lipraxde: 。由於 SSA 的 value 只能被賦值一次的關係，宣告變數12/01 19:45

8^F→Lipraxde: 的一種替代方式就是先 allocate 一塊空間，對其做 load12/01 19:45

9^F→Lipraxde: /store，一般 dependency analysis 是在分析這些 alloc12/01 19:45

10^F→Lipraxde: ate 出來的空間。12/01 19:45

11^F→Lipraxde: 應該是 compiler 要依 backend pipeline 來決定 instru12/01 23:32

12^F→Lipraxde: ction scheduling，dependency 是用來避免 schedule 排12/01 23:32

13^F→Lipraxde: 錯的 (例如本來是 RAW，結果你把 R 排到 W 前面，那 R12/01 23:32

14^F→Lipraxde: 讀到的值就跟沒排前不同)。12/01 23:32

15^F→Lipraxde: 至於 variable def 後到很後面才用到，代表的是這個 va12/01 23:32

16^F→Lipraxde: riable 的 lifetime 很長，不代表它們之間沒有 depende12/01 23:32

17^F→Lipraxde: ncy。12/01 23:32

18^F→Lipraxde: 更正一下：「compiler 要依 backend pipeline...」-> c12/01 23:34

19^F→Lipraxde: ompiler 要參考 backend pipeline...，這樣比較精確12/01 23:34

20^F→Lipraxde: 第一份跑得比較快是因為 br 和 div 可以同時做，而第二12/02 12:24

21^F→Lipraxde: 份要等到 br 做完 (或是 branch predict 有對) 才能跑12/02 12:24

22^F→Lipraxde: ，又因為 mul 需要 div 的結果，mul 不能偷跑。12/02 12:24

23^F→Lipraxde: Data dependency 跟 instruction scheduling 有關，但12/02 12:33

24^F→Lipraxde: 這不代表它就是這個 case 的原因。兩份 binary 的 data12/02 12:33

25^F→Lipraxde: dependency 都一樣，你下的結論從何而來？12/02 12:33

26^F→Lipraxde: 是啊，原因是你的「pipeline一次可以做5個inst」，div12/02 20:05

27^F→Lipraxde: 、mul 間隔的遠只是一種現象。12/02 20:05

[問題] 用 opt 重現 O3

[ CompilerDev ]5 留言, 推噓總分: 0

作者: shane87123 - 發表於 2021/11/27 13:15(4年前)

1^F→Lipraxde: -print-ir-after-all，然後開使 debug 吧，不過你只是11/28 02:20

2^F→Lipraxde: 想插入新的 pass 的話其實直接改 pass builder 就好了11/28 02:20

3^F→Lipraxde: -stats 要有 assertion build11/28 02:20

4^F→Lipraxde: 試試看 -aa-eval，以前好像遇過類似的問題，不過有點忘11/28 15:51

5^F→Lipraxde: 了是因為 lazy analysis 的關係還是啥的11/28 15:51

[問題] frame-pointer 與 performance

[ CompilerDev ]14 留言, 推噓總分: +1

作者: shane87123 - 發表於 2021/11/08 22:11(4年前)

2^F→Lipraxde: Assembly 都在你眼前了，再加點油分析一下。11/09 01:55

3^F→Lipraxde: LLVM 可以在每個 pass 跑完後 dump IR / machine IR，11/09 01:55

4^F→Lipraxde: 對了解優化、為什麼生出這樣的 pattern 很有幫助。11/09 01:55

5^F→Lipraxde: 另外就是不太確定你有沒有讀過 System V ABI，如果要做11/09 01:55

6^F→Lipraxde: 的這麼深的優化的話熟悉 ABI 是很重要的！11/09 01:55

7^F→Lipraxde: 啊...好像講了些不太相干的東西，回到你的問題，雖然給11/09 02:04

8^F→Lipraxde: 的資訊有點少，不過從執行時間的差距、codegen 結果的11/09 02:04

9^F→Lipraxde: 差異來看，我會覺得有可能是由於 cache 所造成的。11/09 02:04

10^F→Lipraxde: Branch miss 呢？11/09 09:19

11^F→Lipraxde: 有開 frame-pointer 的版本因為有多的 push、move 個關11/09 16:50

12^F→Lipraxde: 係，因此不建議直接對 instruction num per cycles 下11/09 16:50

13^F→Lipraxde: 定論。然後我注意到一個地方，all、none 的 instructio11/09 16:50

14^F→Lipraxde: n 數量是差不多的，可以看看是為什麼 :)11/09 16:50

[問題] 兩種不同執行檔產生方式，導致時間不同

[ CompilerDev ]22 留言, 推噓總分: +3

作者: shane87123 - 發表於 2021/11/02 22:58(4年前)

3^F→Lipraxde: 那這樣的話你可以用 opt 去指定跑你要的優化，然後用 l11/03 00:55

4^F→Lipraxde: lc 做 codegen、codegen 的優化。opt、llc 兩個 tool11/03 00:55

5^F→Lipraxde: 分別是用來跑 target-independent、target-dependent11/03 00:55

6^F→Lipraxde: 的 pass pipeline 的11/03 00:55

7^F→Lipraxde: 要跑自己的 pass 去比較差異會比較建議用上述的作法，11/03 01:02

8^F→Lipraxde: 這樣還可以拿到 object file 來看有沒有如預期 codegen11/03 01:02

9^F→Lipraxde: 。用 clang 的話要指定 pass、優化程度比較麻煩，而 ll11/03 01:02

10^F→Lipraxde: i 則是用 interpreter + JIT 的方式，要看到 codegen11/03 01:02

11^F→Lipraxde: 的結果會比較難一些。11/03 01:02

18^F→Lipraxde: 痾... opt -O3 && llc -O2 的 performance 比 opt -O311/03 19:52

19^F→Lipraxde: && llc -O0 還好好像還蠻合理的吧？還是我理解錯你的意11/03 19:52

20^F→Lipraxde: 思？11/03 19:52

21^F→Lipraxde: 如果是做調整 target-independent 的 pass 順序的調整11/05 12:27

22^F→Lipraxde: 的話，把 llc 固定用 O2 吧XD11/05 12:27

[問題] 關於 LLVM 的 APInt 轉換回 unsigned

[ CompilerDev ]4 留言, 推噓總分: 0

作者: eopXD - 發表於 2021/08/26 14:33(4年前)

3^F→Lipraxde: 小於 64bits 的話可以用 getZExtValue、getSExtValue08/26 15:13

[分享] LiteJIT - 支援 X86/RISC-V 的 JIT

[ CompilerDev ]9 留言, 推噓總分: +2

作者: Lipraxde - 發表於 2021/07/12 03:13(4年前)

3^F→Lipraxde: 確實是 object layer 在做的事。其實在做 LiteJIT 更早07/12 18:40

4^F→Lipraxde: 之前，有跟同實驗室的一位同學嘗試 port RISC-V，看能07/12 18:40

5^F→Lipraxde: 不能讓 LLVM 可以直接支援 JIT RISC-V，不過那時好像在07/12 18:40

6^F→Lipraxde: 插 stub、算 address 時遇到了些障礙，做出來的東西還07/12 18:40

7^F→Lipraxde: 不夠用。比較熟 OrcJIT、relocation 後，覺得 OrcJIT07/12 18:40

8^F→Lipraxde: 大部分功能不太需要、relocation 自己做比較快，所以就07/12 18:40

9^F→Lipraxde: 沒去動 LLVM 了 XD07/12 18:40

[分享] 2020 圖靈獎

[ CompilerDev ]3 留言, 推噓總分: +3

作者: LPH66 - 發表於 2021/04/02 14:25(4年前)

1^F推Lipraxde: 恭喜～04/02 19:19

[分享] LLVM 預設使用新的PassManager

[ CompilerDev ]7 留言, 推噓總分: +4

作者: mshockwave - 發表於 2021/02/17 12:35(4年前)

2^F推Lipraxde: Instruction selection 和 register allocation 確實是02/19 22:49

3^F→Lipraxde: 佔蠻多時間，不過在 function 小且數量多的時候花在舊02/19 22:49

4^F→Lipraxde: 的 pass manager 上的時間我是覺得蠻有感的02/19 22:49

5^F→Lipraxde: 不過我不知道換成用新的可以快多少就是了02/19 22:50

[問題] 請教一題Semantic rule

[ CompilerDev ]3 留言, 推噓總分: 0

作者: fmtshk - 發表於 2020/12/23 17:29(5年前)

1^F→Lipraxde: (3) 那邊好像有筆誤，應該是 B.val * 2 ^ (Ls1.len)？12/24 08:04

首頁

尾頁