From 13c5e35222afe0895f0c5e68aa9f22f134ea437a Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Mon, 20 Jul 2009 17:44:17 +0000 Subject: [PATCH] Update this comment. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76438 91177308-0d34-0410-b5e6-96231b3b80d8 --- lib/Analysis/ScalarEvolutionExpander.cpp | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/lib/Analysis/ScalarEvolutionExpander.cpp b/lib/Analysis/ScalarEvolutionExpander.cpp index 20d6e20601f..b6af26a08e5 100644 --- a/lib/Analysis/ScalarEvolutionExpander.cpp +++ b/lib/Analysis/ScalarEvolutionExpander.cpp @@ -215,13 +215,11 @@ static bool FactorOutConstant(const SCEV *&S, /// expandAddToGEP - Expand a SCEVAddExpr with a pointer type into a GEP /// instead of using ptrtoint+arithmetic+inttoptr. This helps -/// BasicAliasAnalysis analyze the result. However, it suffers from the -/// underlying bug described in PR2831. Addition in LLVM currently always -/// has two's complement wrapping guaranteed. However, the semantics for -/// getelementptr overflow are ambiguous. In the common case though, this -/// expansion gets used when a GEP in the original code has been converted -/// into integer arithmetic, in which case the resulting code will be no -/// more undefined than it was originally. +/// BasicAliasAnalysis analyze the result. +/// +/// Design note: This depends on ScalarEvolution not recognizing inttoptr +/// and ptrtoint operators, as they may introduce pointer arithmetic +/// which may not be safely converted into getelementptr. /// /// Design note: It might seem desirable for this function to be more /// loop-aware. If some of the indices are loop-invariant while others -- 2.34.1