[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