Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]>, Lukas =?utf-8?q?Döllerer?= <[email protected]> Message-ID: In-Reply-To: <llvm.org/llvm/llvm-project/pull/[email protected]>
================ @@ -0,0 +1,100 @@ +; RUN: llc -mcpu=mvp -filetype=asm %s -mattr=+branch-hinting -wasm-branch-prob-high=.5 -wasm-branch-prob-low=0.5 -o - | FileCheck --check-prefixes=C1 %s +; RUN: llc -mcpu=mvp -filetype=asm %s -mattr=+branch-hinting -wasm-branch-prob-high=.76 -wasm-branch-prob-low=0 -o - | FileCheck --check-prefixes=C2 %s +; RUN: llc -mcpu=mvp -filetype=asm %s -mattr=+branch-hinting -wasm-branch-prob-high=.75 -wasm-branch-prob-low=0 -o - | FileCheck --check-prefixes=C3 %s + +; C1: .section .custom_section.target_features,"",@ +; C1-NEXT: .int8 1 +; C1-NEXT: .int8 43 +; C1-NEXT: .int8 14 +; C1-NEXT: .ascii "branch-hinting" +; C1-NEXT: .section .text.test2,"",@ +; C1: .section .custom_section.metadata.code.branch_hint,"",@ +; C1-NEXT: .int8 3 +; C1-DAG: .uleb128 test0@FUNCINDEX ---------------- dschuff wrote: Does this actually assemble correctly if you run it through the assembler? This is one of the ULEBs that needs to be padded to 5 bytes, right? I had expected that what we'd need to do for the object file side here would have to avoid the existing .uleb128 directive because my understanding was that it doesn't pad. I had thought that maybe what we'd end up with would just look like a series of bytes emitted for the encoding (which would be a sequence of `.int8` or similar in text assembly), but I realized that that would still be problematic in assembly because there wouldn't be a way to specify the relocation if we did that. Maybe we actually do want to make the `.uleb128` directive pad the LEB if there's a reloc specifier like @FUNCINDEX here... (unless that's what your asm backend change actually does? I haven't looked closely at it yet). If we go that route we'd want an MC test that tests the assembler behavior (i.e. it runs llvm-mc to assemble a .s file and checks the binary output. and then we'd have the whole chain from .ll -> .s and .s to .o) https://github.com/llvm/llvm-project/pull/146230 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
