[all-commits] [llvm/llvm-project] c880d5: [RS4GC] Treat inttoptr as base pointer
Philip Reames via All-commits
all-commits at lists.llvm.org
Mon Jun 7 10:27:43 PDT 2021
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: c880d5e583a389e3a665b2509915533f97dd4792
https://github.com/llvm/llvm-project/commit/c880d5e583a389e3a665b2509915533f97dd4792
Author: Philip Reames <listmail at philipreames.com>
Date: 2021-06-07 (Mon, 07 Jun 2021)
Changed paths:
M llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
A llvm/test/Transforms/RewriteStatepointsForGC/base-inttoptr.ll
Log Message:
-----------
[RS4GC] Treat inttoptr as base pointer
This is a modified version of a patch by tolziplohu with a style change, and most importantly, a revised commit message.
inttoptr for a non-integral address space is currently ill defined in the LangRef. Figuring out exactly what the dynamic semantics of such a cast would be is hard, and not yet settled. Despite that, we still need to go ahead and implement something in RS4GC for a couple of reasons.
First, as a simple consistency argument. We're apparently added support for constexpr inttoptrs a while back, and even have tests which exercised them. Having a lack of constant folding trigger a crash during lowering is non-ideal.
Second, and more fundementally, the optimizer is allowed to insert undefined constructs in unreachable code. At the same time, we can't assume that dynamically dead code is always pruned before lowering. As a result, we must assume that inttoptrs can occur (even if completely ill defined) along dead paths. We need the lowering to not crash. The stackmaps produced can be garbage (as the assumption is the code is dynamically dead), but the lowering itself can't crash.
Differential Revision: https://reviews.llvm.org/D103492
More information about the All-commits
mailing list