[SYCL][thinLTO] Seperate module properties and symbol table generation into IR-based analysis #14220
Conversation
…n into IR-based analysis Signed-off-by: Sarnie, Nick <[email protected]>
| !F.getName().starts_with("__itt")) | ||
| SeenSYCLFunction = true; | ||
| } | ||
| if (SeenESIMDFunction && !SeenSYCLFunction) |
There was a problem hiding this comment.
This logic is new. Previously we used MD.isESIMD()
| // 'if' below essentially preserves the behavior (presumably mistakenly) | ||
| // implemented in intel/llvm#8763: ignore 'optLevel' property for images which | ||
| // were produced my merge after ESIMD split | ||
| if (!SeenESIMDFunction || !SeenSYCLFunction) { |
There was a problem hiding this comment.
This logic is new. Previously we used MD.getEntryPointGroup().Props.HasESIMD != module_split::SyclEsimdSplitStatus::SYCL_AND_ESIMD
Signed-off-by: Sarnie, Nick <[email protected]>
Signed-off-by: Sarnie, Nick <[email protected]>
Signed-off-by: Sarnie, Nick <[email protected]>
Signed-off-by: Sarnie, Nick <[email protected]>
Signed-off-by: Sarnie, Nick <[email protected]>
|
@intel/llvm-reviewers-runtime Does someone mind taking a look? Only relevant change should be adding the new |
Signed-off-by: Sarnie, Nick <[email protected]>
|
@maksimsab Thank you for the review!! I agree it's not costly, but it does incur extra file IO if we write them to disk as we do today (which admittedly should not really be noticeable). The main idea here is that we can seperate out the splitting and props/symtable generation as seperate operations, which is important for thinLTO. |
|
@AlexeySachkov I know you're OOO but I'd like your review on this, I merged it now because there are a lot of changes and I had to rebase/merge almost daily. I'm happy to address any comments in a follow-up PR. |
…n into IR-based analysis (#14220) Based on feedback from #14197, I seperated out the code that generates the module properties and symbol table into separate functions that can be called by anyone, and just looks at the IR and entry points. For now, we still call it inside `sycl-post-link` because we still support the old offloading model, but once we drop support for that we can drop this responsibility from sycl-post-link and only compute it inside `clang-linker-wrapper`, both for normal compilation and thinLTO. In a (hopefully soon) future PR I plan to call these functions from `clang-linker-wrapper` when compiling for thinLTO, which we need because we will split early. Most of this change should be NFC(I). The expected changes are: 1) New option to sycl-post-link to generate the properties file 2) Driver change to NOT pass the option from 1) in thinLTO mode 3) Two minor chages in logic from properties generation, I've called these out inline. --------- Signed-off-by: Sarnie, Nick <[email protected]>
Based on feedback from #14197, I seperated out the code that generates the module properties and symbol table into separate functions that can be called by anyone, and just looks at the IR and entry points.
For now, we still call it inside
sycl-post-linkbecause we still support the old offloading model, but once we drop support for that we can drop this responsibility from sycl-post-link and only compute it insideclang-linker-wrapper, both for normal compilation and thinLTO.In a (hopefully soon) future PR I plan to call these functions from
clang-linker-wrapperwhen compiling for thinLTO, which we need because we will split early.Most of this change should be NFC(I). The expected changes are: