|
From: Peter B. <be...@vn...> - 2013-07-01 20:06:41
|
FYI, I'm the IBM guy adding the GCC HTM support for Power.
Carl has asked me questions wrt valgrind support for HTM, so
I thought I would subscribe to this mailing list to participate
in the conversation.
First off, I'd like to respond to Julian's initial post, but since
that occurred before I joined the mailing list, I'll have to reply
to his post here.
Julian, I agree your (1) proposal is a good and easy starting point,
since valgrind will have to be able to handle the error code path
anyway. However, I think valgrind *will* have to implement something
along the lines of (2) sometime. Implementing (1) now will give us
time to come up with a design for (2) while allowing people to start
executing HTM programs now.
On Mon, 2013-07-01 at 09:28 -0700, Carl E. Love wrote:
> On Fri, 2013-06-28 at 22:16 +0200, Julian Seward wrote:
> > Hi Carl,
> >
> > > would work or not work in Valgrind for the power instructions. Anyway,
> > > any input on the specifics of how I push the simulated execution
> > > directly to the failure path would be helpful. Thanks.
> >
> > I don't know the specifics of the Power instructions, so I can't answer
> > that directly. But I can tell you what the idea was for the Intel
> > instructions -- maybe that would help.
> >
> > (IIRC) the Intel instructions are
> >
> > XBEGIN %reg -- begin a transaction.
> > -- %reg holds the failure-path address
> >
> > XEND -- finish the most recently XBEGIN'd transaction
> >
> > So the idea is very simple: translate XBEGIN %reg as if it was
> > simply a jump to (the code address in) %reg. Does that help?
On Power, a tbegin. instruction sets cr0 to show success or failure
at entering transactional state and updates two new SPR registers:
Transaction EXception And Summary Register (TEXASR):
This register is normally used by failure handlers for
determining why a transaction failed, but it also holds
information about the depth of nested transactions we
currently have.
Transaction Failure Handler Address Register (TFHAR):
This register holds the address the hardware will start
executing from upon a transaction failure/abort. It is
initialized by the tbegin. instruction to CIA+4 (in IBM
parlance), which means it contains the address of the
instruction immediately following the tbegin. instruction.
It can be modified by a "mtspr TFHAR,<reg>", but that
should be a fairly rare occurrence. Similar to x86's
common usage, where the xbegin's %reg is set to the
address following the xbegin.
There is one more HTM SPR register:
Transaction Failure Instruction Address Register (TFIAR):
This register holds the address of the instruction
that caused the transaction failure (when possible).
On Power, to implement (1), we just need to have the tbegin. instruction
return failure by setting cr0 to 0b0010 (ie, 0x2), set the TFHAR to
CIA+4 and then begin executing at the address in the TFHAR.
We'll need to choose a reason why the transaction failed. so we can
initialize the TEXASR and TFIAR for use in the failure handler code.
I highly suggest setting the PERSISTENT flag in the TEXASR, since that
is a hint to the failure handler that this failure is not likely to
go away and retrying the transaction will likely fail. Normally
failure handlers will not retry a hardware transaction if the failure
is marked persistent. A possible failure we could use is that we
hit a resource limit on the number of allowable nested transactions
(heh, one is one too many :).
For the other Power htm instructions, they basically just act as nops
when we're in non-transactional state, so implementing them for (1)
should be straightforward, since we're always in non-transactional
state.
> From what I understand of the power implementation (I have some
> questions for the IBM compiler people) is that the instruction following
> the tbegin will be a branch instruction with the address of the failure
> path. So I guess we could do something similar.
Normally, that is the case, but it doesn't have to immediately follow
the tbegin. ... and it may not even exist, depending on the code we
compiled, so you cannot rely on it being there. That also doesn't
cover the case where the user updates the TFHAR with an address,
so on failure, we don't even branch to the instruction following
the tbegin., but rather to the new address the user stuffed into
the TFHAR.
> However I have some
> concerns. One concern is, what guarantee do we have that the outcome of
> the failure path would be functionally equivalent to the transactional
> path?
There is no guarantee they are functionally equivalent. That can be
due to stupid or untested buggy code or for valid reasons, like a
real hardware transaction shouldn't fail for some specific transactions
and so the programmer omitted the failure handler. Either way, for
(1), I don't think we should sweat it too much, since the former is
totally a user error and they get what they get, while for the latter,
there's nothing we can do until we have (2) working.
> Seems like we are at
> the mercy of whatever the programmer chooses to do in the case of a
> failure. I need to chat with our compiler people about that question.
> I guess in theory the programmer could chose throw up his hands and just
> call exit(1) if the transaction failed. In that case, Valgrind would
> never be able to reproduce a successful run of the program on real
> hardware where there was no TM issues during the run.
Correct, we are at the mercy of whatever the programmer decides to
do when a transaction fails, but if they decide to throw their hands
up in the event of errors, well... that's stupid, but that's their
business. Note that there's nothing special here wrt valgrind that
doesn't also apply to real htm hardware failing for some reason.
The only caveat are the special transactions that normally would never
fail on real hardware, but that will be covered if/when Julian's (2)
proposal is implemented.
As for Julian's (2) proposal, I haven't had time enough to think about
possible solutions, and whether we could (or even should?) possibly rely
on the underlying HTM hardware to help us. I am eager to hear other
people ideas though, if they have them.
Peter
|