Re: prevent optimisation of variables on SSA
Hi Richard,
thank you very much for your suggestions, it seems to be working well.
Now, the temporary variables survive the SSA optimisations.
and the txn_save_* variables are optimised "away". Is there any way to
prevent this kind of optimisations on SSA form for a particular group of
variables? Here I would like to see the txn_save_* variables behave as a
container for the values of the real variables and be sure that these
variables are not touched by any optimisations.
Well, if you are inserting this abnormal control flow after going into SSA
then you need to make sure all SSA variables affected are marked
as SSA_NAME_OCCURS_IN_ABNORMAL_PHI and make sure that
SSA names from a single base variable not have overlapping life-ranges.
Currently, the control flow and some function calls for setting up a
transaction are introduced on GIMPLE. Thus, when the program is
rewritten into SSA the function calls to stm_* force the merging of
overlapping live ranges of single base variables:
I tried it with Diegos nice example and introduced the call to stm_new
in the following:
int
foo(int a, int b, int c)
{
void * txn_handle;
a = b;
if (c < a)
{
b = b + a;
c = c + a;
}
txn_handle = stm_new ();
return b + c;
}
Usually, b has two overlapping live ranges where the stm_new was
introduced and going into SSA shows the following:
foo (a, b, c)
{
void * txn_handle;
int D.1184;
int D.1183;
# BLOCK 2
# PRED: ENTRY (fallthru)
a_4 = b_3(D);
if (c_5(D) < a_4)
goto ;
else
goto ;
# SUCC: 3 (true) 4 (false)
# BLOCK 3
# PRED: 2 (true)
b_6 = b_3(D) + a_4;
c_7 = c_5(D) + a_4;
# SUCC: 4 (fallthru)
# BLOCK 4
# PRED: 2 (false) 3 (fallthru)
# b_2 = PHI
# c_1 = PHI
D.1183_8 = stm_new ();
txn_handle_9 = (void *) D.1183_8;
D.1184_10 = b_2 + c_1;
return D.1184_10;
# SUCC: EXIT
}
The PHI-node to merge the two live ranges is introduced before the call
to stm_new(). I believe this solves my problem because the checkpointing
would be done afterwards and there only b_2 remains to checkpoint. Do
you agree?
Which means what you are doing is not really going to be easy in
SSA form and you should rather try to do it before going into SSA.
And I would suggest you use the exception handling machinery of
GCC to do it and not insert setjmp/longjmp calls yourself or try to
track the complete program state.
You are right to propose to use the exception handling machinery to do
the handling of setjmp/longjmp. But I see two issues with this approach:
first, I am not experienced in programming GCC and don't know how to use
this machinery. Second, the longjmp is executed by the library and,
thus, not part of the implementation in GCC. I am not sure if this
affects the EH mechanisms but I can imagine it could.
Regards,
Martin
Re: prevent optimisation of variables on SSA
On 8/18/08 7:15 AM, Martin Schindewolf wrote:
txn_handle.12_4 = __builtin_stm_new ();
jmp_buf.13_5 = __builtin_stm_get_env (txn_handle.12_4);
ssj_value.14_6 = _setjmp (jmp_buf.13_5);
if (ssj_value.14_6 == 0)
goto ();
else
goto ();
# SUCC: 4 (false) 3 (true)
# BLOCK 3
# PRED: 2 (true)
:;
__builtin_printf ("SAVE_BB\n");
txn_save_m.19_15 = m_1;
txn_save_a.20_20 = a_2;
txn_save_b.21_25 = b_3;
fake_var.18_13 = __builtin_stm_dummy ("RECOVER_BB\n");
if (fake_var.18_13)
goto ();
else
goto ;
# SUCC: 4 (true) 5 (false)
# BLOCK 4
# PRED: 2 (false) 3 (true)
# txn_save_b.21_26 = PHI
# txn_save_a.20_21 = PHI
# txn_save_m.19_16 = PHI
:;
__builtin_printf ("RECOVER_BB\n");
m_17 = txn_save_m.19_16;
a_22 = txn_save_a.20_21;
b_27 = txn_save_b.21_26;
# SUCC: 5 (fallthru)
# BLOCK 5
# PRED: 4 (fallthru) 3 (false)
# m_18 = PHI
__builtin_stm_start (txn_handle.12_4, jmp_buf.13_5, &0);
Your problem seems to be that you are introducing irregular control flow
with your setjmp buffers. Perhaps you could express this transformation
in High GIMPLE and use try/catch or try/finally? Those are then
converted into a lowered form, but that means using the internal EH
machinery.
Another option is to mark the SSA names as ocurring in abnormal PHIs
(SSA_NAME_OCCURS_IN_ABNORMAL_PHI). But I'm not sure if that's going to
be straightforward.
Diego.
Re: prevent optimisation of variables on SSA
On 8/15/08 1:00 PM, Martin Schindewolf wrote: Hi all, I currently introduce a temporary variable on SSA form but it does not survive the SSA optimisation passes. (Not even the simple ones triggered with -O1). Since the temporary variable is considered to be a gimple register it is not possible to set a VUSE or VDEF for it. (I tried and it breaks the SSA properties). Are there any mechanisms to work around this restriction and set the VDEF/VUSE anyway or is there a way to tell the SSA optimisers not to touch this variable (or SSA_NAME)? Thank you very much for sharing your thoughts! You are not providing enough information. Is the creating assignment for the new SSA variable dead? If there are no uses of your new variable, then DCE will remove the assignment. Diego.
GCC 4.3.2-rc1 available
GCC 4.3.2-rc1 is now available from <ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.2-RC-20080819>. 4.3 branch remains in the state that all changes require release manager approval, until 4.3.2 is released. GCC 4.3.2 will follow in about a week in the absence of any significant problems with 4.3.2-rc1. If you believe a problem should delay the release, please file a bug in Bugzilla, mark it as a regression, note there the details of the previous 4.3 releases in which it worked and CC me on it. Anything that is not a regression from 4.3.0 or 4.3.1 is unlikely to delay this release; new fixes for regressions from 4.2 and earlier releases can go in 4.3.3 and later 4.3 releases, or in 4.3.2 if they are ready on time and seem safe enough considering the severity of the regression. -- Joseph S. Myers [EMAIL PROTECTED]
Something general (beginner related)
Hi folks. Maybe the one or another remembers the post I've wrote more than a month ago. I was (and still am) new to the GCC codebase and had the evil plan to add an optimization pass to do byte permutations (capturing all home-brewed bswap things and all the other 23 possible byte-permutations as well). Well - I had a lot of time to kill during the last weeks, and I had a lot of timeto read into the source. Business trips without internet access are a perfect opportunity to read such stuf... Anyway, after all this passive read-work, I've been able to add the humble beginnings of my pass. I'm now able to and I've been able to run a code that does a printf as soon as I find an structure in the SSA tree that is a potential candidate for my optimization. However, approaching this point has been very painfull and I'm far away from chainging anything in the SSA. Let's get to the point: The documentation sucks. If you want to learn how things work the wiki and the documentation is of little help. You have to read other code, step through other optimizations and do a lot of reverse-engineering and code-reading to understand how all the different things fit and relate to each other. I think a well commented pseudo-pass (well document as: talk to someone who know C but has no idea about the GCC magic..) that does something stupid but valid like re-inventing the neg-operator by using not and subtraction could act as be a very nice boilerplate code for people like me. For someone who is into the SSA structures and the gcc internals should be able to write up something within a day or an half. Just an idea.. And just to let you know how hard it can be: Finding out what GTY means *can* take half a day... Nils
Re: Something general (beginner related)
On Wed, Aug 20, 2008 at 12:21:42AM +0200, Nils Pipenbrinck wrote: > Well - I had a lot of time to kill during the last weeks, and I had a > lot of timeto read into the source. Business trips without internet > access are a perfect opportunity to read such stuf... > > Anyway, after all this passive read-work, I've been able to add the > humble beginnings of my pass. I'm now able to and I've been able to run > a code that does a printf as soon as I find an structure in the SSA tree > that is a potential candidate for my optimization. > > However, approaching this point has been very painfull and I'm far away > from chainging anything in the SSA. > > Let's get to the point: The documentation sucks. If you want to learn > how things work the wiki and the documentation is of little help. You > have to read other code, step through other optimizations and do a lot > of reverse-engineering and code-reading to understand how all the > different things fit and relate to each other. You may be in a unique position to do something about this problem, as someone who has just had to painfully learn how to write a pass. You could write up what you've learned on a wiki page, and we might be able to convince some more experienced people to help correct anything you got wrong. > I think a well commented pseudo-pass (well document as: talk to someone > who know C but has no idea about the GCC magic..) that does something > stupid but valid like re-inventing the neg-operator by using not and > subtraction could act as be a very nice boilerplate code for people like me. Alternatively you could contribute that. > For someone who is into the SSA structures and the gcc internals should > be able to write up something within a day or an half. Right, but in many cases the people that know this stuff cold don't have a day and a half, so it will happen when someone contributes it.
Re: Creating own Backend: Segmentation fault in mark_jump_label_1
Balthasar Biedermann schrieb: > I create a gcc-backend. I have already created the *.md, *.h and *.c > files and I have compiled the gcc which includes backend. > > But when I try to compile a simple c-File with my gcc I get a > Segmentation fault. I tried to debug it but I don't get the point. > > The Error occures in mark_jump_label_1. It is called with a null pointer > as the rtx x. > > Which Target Makro or which machine description could create such an error? > Does nobody have an idea why or where the error occures? I really start to became desperate. I already changed a lot of Makros and analysed the the resulting gcc with gdb but I can't fix the error. I'm really grateful for every help! signature.asc Description: OpenPGP digital signature
Re: Creating own Backend: Segmentation fault in mark_jump_label_1
> > The Error occures in mark_jump_label_1. It is called with a null pointer > > as the rtx x. > > Does nobody have an idea why or where the error occures? I really start > to became desperate. I'm sure plenty of people have an idea of why the error occurs. However, you need to be clearer in explaining the problem so that people have at least some hope of helping you, or doing so without consuming excessive amounts of time from their schedules. > I already changed a lot of Makros and analysed the the resulting gcc > with gdb but I can't fix the error. I'm really grateful for every > help! Perhaps you could get a stack backtrace and try to understand why you're getting a NULL_RTX passed in? Ben
