What do you mean by immediately? Earlier the interrupts were handled
only at the beginning of the commit cycle. Now they can be handled 
in the middle of the commit cycle as well. What can happen, and I 
have seen this, that there are no instructions in the pipe and the 
head instruction was delayed commit. For example, if the head inst 
is marked IsSquashAfter, it can empty the pipe, independent of 
whether or not it is delayed commit. Hence, we need the check.

What i mean is that currently the (attempted behavior) is that when an interrupt is signaled the CPU is drained of all instructions and the interrupt is handled. It seems like this might be changing things to interrupt as soon as possible based on the delayed commit flag and not drain the pending instructions in the pipe. 

No, the condition for handling interrupts has only been strengthened.
The previous condition that cpu's instList be empty has been retained. 
This means when an interrupt is handled, the instList is empty and the
last committed microop was not marked delayed commit.

If I understand Ali's point, the difference he's referring to is that previously handleInterrupt() could only be called at most once per call to commit() (at the beginning), where now handleInterrupt() is inside a loop and so it could be called more "immediately" in the sense that if the conditions for calling handleInterrupt() become true in the middle of the loop it would get called right away rather than waiting to the next call to commit().

Steve, what you are saying is true, but what is also true is that the 
cpu's instList would be empty. That condition has not been removed.

It might be that calling handleInterrupt() once will be sufficient.
I was initially trying not to rely on the fetch stage to stop supplying
instructions when an interrupt needs to be handled. I felt that the 
function handleInterrupt() should be called in the loop, as a non-delayed 
commit microop may never get committed just at the end of the loop. That 
some how did not work, possibly because of other things that need to fixed 
with the fetch stage. These other things might have been fixed with 
another patch that I have posted. But I retained calling handleInterrupt()
in the loop.

Interrupts can only be handled by the thread with tid 0, so this
check is required. I think we can elide this check, if assume that
number of threads will always be set to 1. The Alpha pal-mode check
has been copied from the fetch stage. It might be possible that the
committed microop is marked non-delayed but is still a microop in the
pal-code. In this, case we do not want to handle the interrupt now.

Where does the tid 0 restriction come from?  It's probably moot since I don't know of any ISAs for which we support SMT in FS mode, but it seems odd that a "new" restriction is being introduced here in commit that wasn't here previously.  Similarly for the Alpha pal-mode check... why is it necessary to do this in commit now when it wasn't necessary before?

Given my understanding of the code, there is no new restriction 
being introduced. Interrupts were always handled using thread 0.
We any way need some check to ensure that the last microop of the
thread that handles the interrupt was marked non-delayed. It is
possible to introduce an array of booleans to maintain per thread
flag. But that seems unnecessary if only thread 0 is going to handle
the interrupt.

The pal-mode check is necessary since interrupts cannot be handled
in pal-mode. It was not there before does not mean that what ever
was happening before was correct. Even the check for delayed commit
was not there before. By this logic, the entire patch would seem unnecessary.

I'm saying "new" because this code is appearing seemingly out of nowhere with respect to this patch.  If these are restrictions you're copying from somewhere else, that's fine, but where is that other code?  Is it still necessary in that other place?  And if we're going to have conditions like this in multiple places, would it be a good idea to capture them in a function that gets called from both places rather than having the logic duplicated in a way that makes it prone to getting changed in one place and not the other?

The code as such appears in 2 or 3 functions. If you read the file commit_impl.hh,
you would find that the there are places where certain conditions are being 
set / checked only for thread 0. It seems odd as to why one may want to prefer
thread 0 for handling interrupts or differentiate amongst threads. It might be that
there are some problems with handling interrupt with other threads, though I am not
aware of any.