With opaque pointers, no actual bitcasts will be present. Instead, there will be a mismatch between the call FunctionType and the function ValueType. Change the code to collect CallBases specifically (rather than general Uses) and compare these types.
Details
- Reviewers
aheejin tlively - Group Reviewers
Restricted Project - Commits
- rG7f058ce8c2cb: [WebAssembly] Support opaque pointers in FixFunctionBitcasts
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp | ||
---|---|---|
84–86 | I dropped the RAUW call on constants that this is guarding against. With opaque pointers, there is no bitcast to RAUW (the only thing that could be potentially RAUWd is the GlobalAlias case). I'm not sure if dropping the RAUW call itself is problematic, at least there was no test coverage for why it would be needed. I could imagine something like a function bitcast being called directly in one place, and then also being stored to memory in another place and then called indirectly or something like that? Though that already wouldn't work if there is no direct call and only indirect calls. So I'm not really sure why it was there. |
Why can this logic be removed?