This change also removes DEBUG(dbgs() << "SCEV: untested prestart overflow check\n"); because that case has a unit test now.
Details
Diff Detail
Event Timeline
Thanks for generalizing this. It would seem simpler to define an ExtendOpTraits base class parameterized on ExtendOp instead of triplicating the typedef. Otherwise LGTM.
I can't remember if there are other places we've tried to generalize SCEV extension ops. I don't see anything off hand.
I can see how my comment about duplicating the typedef would seem silly. I was actually thinking about bringing the members defined by that type into the base, as shown below. But I didn't think it through because now that I write it out, the out-of-line static definitions are utterly horrid:
template <SCEV::NoWrapFlags W, GetExtendExprTy ExtendF,
GetOverflowLimitForStepTy OverflowF>
struct ExtendOpTraitsBase {
static const SCEV::NoWrapFlags WrapType = W; static const GetExtendExprTy GetExtendExpr; static const GetOverflowLimitForStepTy GetOverflowLimitForStep;
};
template <SCEV::NoWrapFlags W, GetExtendExprTy ExtendF,
GetOverflowLimitForStepTy OverflowF>
const GetExtendExprTy ExtendOpTraitsBase<W, ExtendF, OverflowF>::
GetExtendExpr = ExtendF;
template <SCEV::NoWrapFlags W, GetExtendExprTy ExtendF,
GetOverflowLimitForStepTy OverflowF>
const GetOverflowLimitForStepTy ExtendOpTraitsBase<W, ExtendF, OverflowF>::
GetOverflowLimitForStep = OverflowF;
template <typename ExtendOp> struct ExtendOpTraits {};
template <>
struct ExtendOpTraits<SCEVSignExtendExpr>
: public ExtendOpTraitsBase<SCEV::FlagNSW, getSignExtendExpr, getSignedOverflowLimitForStep>
{};
template <>
struct ExtendOpTraits<SCEVZeroExtendExpr>
: public ExtendOpTraitsBase<SCEV::FlagNUW, getZeroExtendExpr, getUnsignedOverflowLimitForStep>
{};
Oh well, at any rate, you shouldn't need to refer to the type like this anymore:
ExtendOpTraits<SCEVSignExtendExpr>::GetExtendExprTy
Looks like I misinterpreted your review comment. :) Does what I
checked in look okay though?
- Sanjoy
Hi all -
This patch appears to be responsible for a new miscompile detailed in:
http://llvm.org/bugs/show_bug.cgi?id=22641