[llvm-commits] [LLVM, SwitchInst, case ranges] Auxiliary patch #1
Stepan Dyatkovskiy
STPWORLD at narod.ru
Fri Jan 6 01:02:33 PST 2012
> My half-baked thought was that we could store 1, 4...7, 12 as [1, <4, 7>, 12], just to distinguish ranges from pairs of scalar values.
May be ConstantStruct? Something like this:
struct { // 0-level struct represents set of values and ranges.
unsigned v1 = 1;
struct { // 1-level struct represents ranges, and must have two fields only: "low" and "high".
unsigned low = 4;
unsigned high = 7;
} v2;
unsigned v3 = 12;
}
>> CaseValue = SI->getOperand(SomeIndex); // We use User methods keeping SwitchInst format in mind.
>> CaseSuccessor = SI->getSuccessor(SomeIndex2); // We use TerminatorInst methods keeping what each successor means in mind.
>> with
>> CaseValue = SI->getCaseValue(SomeCaseValueIndex);
>> Successor = SI->getCaseSuccessor(SomeSuccessorIndex);
>
> I may not be understanding what you mean, but I think that getting rid of getOperand() (hiding it in SwitchInst) makes sense. getSuccessor() still needs to exist though.
Now 0-case value is not a case value instead. It is a Condition. The same with successors. Zero-indexed successor is default destination (not a case successor). We store items with different types and roles in single collection.
I propose totally separate this terms on SwitchInst level: to use getCondition() if you need condition, use getDefaultDest() for default destination. Use getCaseValue only for resolving some case value. So getCaseValue(0) means that I need first case value (not condition) and getCaseSuccessor(0) means that I need successors for first case value (not default dest). Ideally, developer that uses SwitchInst should know nothing about internal operators format.
-Stepan.
More information about the llvm-commits
mailing list