In D76909#1983203, @dmgreen wrote:

Ping!

Abandoning as I think I will try a more holistic approach.

In D68685#1716040, @HsiangKai wrote:

In D68685#1714378, @jrtc27 wrote:

I wonder whether, instead of putting all the scheduling resource information as part of the instruction definition, we should be doing something like we do with patterns, ie declaring them separately (either in each RISCVInstrInfoX.td, or in RISCVSchedule.td to keep scheduling completely separate from encoding and codegen). For example (formatting aside):

def : InstRW<[WriteFALU32], (instrs FADD_S, FSUB_S, FSGNJ_S, FSGNJN_S, FSGNJX_S, FMIN_S, FMAX_S)>;

In general, InstRW is used to describe subtarget-specific scheduling behavior for specific instructions. If we use InstRW to describe the whole pipeline model, we need to create the mappings between scheduling types (SchedReadWrite) to instructions for every subtarget. It is a tedious work when adding a new subtarget for the target. I think it is more reasonable to associate SchedReadWrite list to instructions for target and specify latencies and cycles to these SchedReadWrite in subtarget. We only need to associate SchedReadWrite list to instructions only once and specify latencies and cycles for every subtarget. It is more modular and it is easier for subtarget.

updated based on review comments

Is there a forwarding mechanism in Rocket? If so, that can be added to make the model more accurate.

Hi Michael:

In D68685#1705570, @rogfer01 wrote:

@javedabsar (or @javed.absar) I seem to recall you have experience with schedulers. If you could give us a hand here that'd be great! :)

In D68453#1695855, @hfinkel wrote:

In D68453#1695803, @javed.absar wrote:

In D68453#1694815, @hfinkel wrote:

How far down this road can we go? I would like to see infix operators in TableGen because I believe that it will make it easier to use. However, I'm concerned about just adding add as a special case. Of the other similar operators:

case ADD: Result = "!add"; break;
case MUL: Result = "!mul"; break;
case AND: Result = "!and"; break;
case OR: Result = "!or"; break;
case SHL: Result = "!shl"; break;
case SRA: Result = "!sra"; break;
case SRL: Result = "!srl"; break;
case EQ: Result = "!eq"; break;
case NE: Result = "!ne"; break;
case LE: Result = "!le"; break;
case LT: Result = "!lt"; break;
case GE: Result = "!ge"; break;
case GT: Result = "!gt"; break;

how many can we add as infix operators without ambiguities or other difficulties?

I have a half baked shunting-algorithm based infix-operator patch to work with cases you mention but that is kind of major work. I thought maybe, as !add is most commonly used, there maybe an appetite for a simple solution like here.

To be clear, I'm fine with taking an incremental approach here. It sounds like you've investigated this and there's no major technical impediment, it's just more complicated (and, thus, a more-complicated patch) to deal with all of the operators. Is that correct?

In D68453#1694815, @hfinkel wrote:

How far down this road can we go? I would like to see infix operators in TableGen because I believe that it will make it easier to use. However, I'm concerned about just adding add as a special case. Of the other similar operators:

case ADD: Result = "!add"; break;
case MUL: Result = "!mul"; break;
case AND: Result = "!and"; break;
case OR: Result = "!or"; break;
case SHL: Result = "!shl"; break;
case SRA: Result = "!sra"; break;
case SRL: Result = "!srl"; break;
case EQ: Result = "!eq"; break;
case NE: Result = "!ne"; break;
case LE: Result = "!le"; break;
case LT: Result = "!lt"; break;
case GE: Result = "!ge"; break;
case GT: Result = "!gt"; break;

how many can we add as infix operators without ambiguities or other difficulties?

In D62394#1672551, @sigvartmh wrote:

Maybe I'm doing something wrong tried to apply these patches but when trying to build code which uses cmse I get

Cannot select: intrinsic %llvm.arm.cmse.tt
fatal error: error in backend: Cannot select: intrinsic %llvm.arm.cmse.tt
clang-10: error: clang frontend command failed with exit code 70 (use -v to see invocation)

Built llvm with clang,compiler-rt,lld from master.

LGTM. Sorry for the delay

Would this end up prioritising 'resourcelimited' too much? Looks like there can be performance differences between before and after this change - any numbers / thoughts on that?

Updated based on review comments

Hi Tim:
Have made the changes as suggested. Please have a look.

Tests merged as suggested.

Fixed as suggested

Thanks for this. Its good you show a use-case but probably the use case can be a separate commit.

LGTM , except for a small nitpick.

ping!

ping!

Ping!

Added BNF grammer for !cond as suggested .

Hi all:
I have made the changes as requested. That is, removed explicit 'default' while sticking to overall syntax as before. I found that removing default in fact simplifies the implementation somewhat. Also, have split the tests to cleaner separate ones.

Hi Hal/Others:

I have changed the syntax from !ifs to '!cond' now, while retaining the others parts from original !ifs (instead of from LISP). Please let me know if changes are ok with you.

Thanks

Changes based on review comments. The new operator is now called '!cond', and 'default' must be the last clause.

LGTM but will wait for a while to allow others comment as well, if necessary.

LGTM

LGTM. Thanks for this.