Apply TBAA metadata in the LLVM backend. #921
Conversation
…LVMFunctionCodeGenerator. Use that to generate distinct TBAA labels for distinct local variables.
…ses off the context. Move tbaa_label to intrinsics.rs. Move TBAA pass to first in the list, it doesn't get invalidated. Add TBAA labels for internal fields.
| @@ -1027,3 +1164,43 @@ impl<'a> CtxType<'a> { | |||
| } | |||
| } | |||
| } | |||
|
|
|||
| pub fn tbaa_label( | |||
There was a problem hiding this comment.
Can you document this part specifically please? Ideally, it should explain what TBAA means (is it Type Based Alias Analysis?), what it is used for, and some examples. Thanks!
There was a problem hiding this comment.
I added comments both to the function declaration, what it does for the caller, and in its implementation, how it does what it achieves, with the goal that a future developer could follow along with the newly commended code in one hand and the LLVM TBAA documentation in the other.
I didn't add examples. Let me know if you'd like me to extend the comments further.
Hywan
added
🎉 enhancement
|
Is there a way to test this new feature? |
Don't I wish!! The difference is only visible to the user in two ways, different generated object code (and with it different size and performance), and different LLVM IR (which in turn generates the different object code). We have some debugging flags --llvm-object-file and --llvm-post-opt-ir and --llvm-pre-opt-ir, but we don't have any tests for those either (and indeed they were broken for a while due to their lack of testing). I've asked @MarkMcCaskey how we should test those flags, but we didn't have any good ideas so I left it. I'd like to start by testing those flags, then we use them to test changes to the LLVM backend. If we make a change like adding TBAA, that leads to a pre-opt-ir change, changing the pass pipeline to take advantage of TBAA leads to a post-opt-ir change, and object file change. Changing whether we emit PIC code only causes an object file change. Unfortunately, if we simply had golden file tests, making any of these three changes would impact every single test. I'd welcome any ideas on how to write good tests for this. |
Memory can't change between static and dynamic, so use that in the TBAA label name. Distinguish between local and imported memory, table and globals.
|
bors r+ |
921: Apply TBAA metadata in the LLVM backend. r=nlewycky a=nlewycky # Description Inform LLVM that the pointers to memory, globals, locals, etc., are distinct. # Review - [ ] Add a short description of the the change to the CHANGELOG.md file Co-authored-by: Nick Lewycky <[email protected]> Co-authored-by: nlewycky <[email protected]>
Build failed
|
|
bors r+ |
921: Apply TBAA metadata in the LLVM backend. r=nlewycky a=nlewycky # Description Inform LLVM that the pointers to memory, globals, locals, etc., are distinct. # Review - [x] Add a short description of the the change to the CHANGELOG.md file Co-authored-by: Nick Lewycky <[email protected]> Co-authored-by: nlewycky <[email protected]>
Build succeeded
|
Description
Inform LLVM that the pointers to memory, globals, locals, etc., are distinct.
Review