[llvm-commits] [PATCH] TableGen backend support to express relations between instruction

[Jyotsna Verma]

Thanks Pranav for your comments. My response is below.

> I think you should add comments to give a near-complete example of how a
> particular instruction mapping would look For instance, if you could
explain
> how the predication mapping would look, that'll be really helpful.

Here is the example usage of the functionality:

If we want to relate non-predicated instructions with their predicated
forms, we can define the relationship as follows:

def getPredOpcode : InstrMapping { // InstrMapping is a new class defined in
Target.td

// Used to filter instructions that have this kind of relationship
 let FilterClass = "PredRel";

// Instructions with the same BaseOpcode value form a row.
let RowFields = ["BaseOpcode"];

// Instructions with the same predicate sense form a column.
let ColFields = ["PredSense"];

// The key column is the unpredicated instructions.
let KeyCol = ["nopred"];

// Value columns are PredSense=true and PredSense=false
  let ValueCols = [["true"], ["false"]];
 }

We can use the above relationship to map non-predicate 'Add' with its
predicate form by just setting BaseOpcode and PredSense values like this:

Def ADD: PredRel {
   let BaseOpcode = "ADD";
   let PredSense = "nopred";
}

Def ADD_pt: PredRel {
   let BaseOpcode = "ADD";
   let PredSense = "true";
}

Def ADD_pf: PredRel {
   let BaseOpcode = "ADD";
   let PredSense = "false";
}

Here if you notice, BaseOpcode is same for all 3 instructions and is used to
group them together. Similarly, we can relate 'Sub'/'Xor' with their
predicate forms by setting BaseOpcode which is unique for that subgroup.

> Alternately, you could consider adding a section to the TableGen
> documentation maintained on llvm.org.

I was planning to do that but then I found that the TableGen documentation
on llvm.org doesn't contain information about any of the TableGen features.
So, I decided not to do it for this feature as well.

> Another thing, will this table (predSense) have three columns (nopred,
true & false) or only two (true, false) ?

It's yes and no depending on the table representation. For smaller tables,
we emit only instructions with valid relations. In this case, we do emit key
instruction in the first column as we perform binary search on the table.
When table sizes (one or more) cross a threshold value, we generate a
cumulative table which is optimized for space and access time. In this case,
we don't emit the key instruction. Instead, it is included in the comment.
If you are interested, I can send you a sample output.

> >+  // Emit function to performs binary search on relation tables.
> >+  void emitBinSearchFunc(raw_ostream &OS);
> 
> <NitpickingStart> s/performs/perform/ <NitpickingEnd>

Thanks for pointing it out.
 
> Should you not assert if the size of KeyInstrVec is 0? Shouldn't a mapping
> have atleast one Key instruction ?

I don't assert if relation table is empty. Instead, I add a dummy entry in
table for INSTRUCTION_LIST_END. I found it more useful especially while
adding new relations.

Thanks,
Jyotsna
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation