Add ability to parse empty control with attributes

[rachitnigam]

Okay, this is an admittedly weird thing to do but: this PR adds the ability to parse empty control blocks when they have attributes.

The Good

For example, this can be parsed now:

control {
  @sync; // <-- note the semicolon
}

The reason is that it gives us to experiment with "proto-keywords" like more easily. We currently have the philosophy of trying features out using attributes before we turn them into full blown keywords.

For example, the @sync keyword is an example. The current semantics is that for a program like this:

control {
  @sync A; B;
}

The synchronization happens before A executes. This means that sometimes we have to write programs like this:

control {
  if lt.out {
    @sync no_op;
  } else {
    @sync A; B;
  }
}

Where the no_op group doesn't do anything. With this change, we can write:

control {
  if lt.out {
    @sync;
  } else {
    @sync; A; B;
  }
}

This also has the pleasant outcome of making the meaning of @sync clearer---the synchronization occurs before the group executes. We also don't need to have special handling for invoke.

The Bad

The bad thing is that this is an empty which means that it shouldn't really have any semantics and should be erasable? This would make it important for passes to keep empty control programs around when they have an attribute attached.

On the other hand, imagine the possibilities–a @log keyword for print out values? @delay to insert fake delays between par threads to test their delay insensitivity?

[paili0628]

I think this is a great thing as it certainly makes the semantics of sync clearer. Let me try to change the sync test cases to see if this gets compiled properly to barriers

[EclecticGriffin]

hmm, I can kinda see this for sync but I have some misgivings. On the whole the idea of using empty groups with special attributes seems to me a means of hacking in a set of auxiliary control psuedo-commands (pragmas?) that influence compilation but don't correspond to group-type compilation flows. And if that's what we want, it might be better to let those types of commands stand alone.

lmk if this makes any sense. This is just my initial reaction so I am open to being persuaded.

[rachitnigam]

@EclecticGriffin absolutely! Thinking of these as pseudo commands is pretty much what I was going for. I agree that we would eventually want to turn all of these into real control operators to do it “the right way”

Having this backdoor is more a question of making it easier to experiment with things quickly. Adding a new command is an infrastructure-wide change while adding a new attribute is trivial.

In fact, it also makes it easier for someone outside of the core team to play with new control like operators because all they have to do is add the attribute and write a pass to interpret it

[EclecticGriffin]

makes sense to me!

[sampsyo]

Yeah, I too agree that this is a strange but creative solution to the problem! Seems like a good idea to run with it. In all fairness, attributes were already not "semantics-free"… especially in the case of @sync, your program's correctness really relies on the synchronization actually happening. So this is not much of a slide down the slippery slope, IMO, and it does open the door to interesting non-built-in control statements.