Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Tue, Nov 27, 2012 at 1:06 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Richard,
I spent a good part of the afternoon talking to Mike about this. He is on
the c++ standards committee and is a much more seasoned c++ programmer than
I am.
He convinced me that with a large amount of engineering and c++
foolishness that it was indeed possible to get your proposal to POSSIBLY
work as well as what we did.
But now the question is why would any want to do this?
At the very least you are talking about instantiating two instances of
wide-ints, one for the stack allocated uses and one for the places where we
just move a pointer from the tree or the rtx. Then you are talking about
creating connectors so that the stack allocated functions can take
parameters of pointer version and visa versa.
Then there is the issue that rather than just saying that something is a
wide int, that the programmer is going to have to track it's origin. In
particular, where in the code right now i say.
wide_int foo = wide_int::from_rtx (r1);
wide_int bar = wide_int::from_rtx (r2) + foo;
now i would have to say
wide_int_ptr foo = wide_int_ptr::from_rtx (r1);
wide_int_stack bar = wide_int_ptr::from_rtx (r2) + foo;
No, you'd say
wide_int foo = wide_int::from_rtx (r1);
and the static, non-templated from_rtx method would automagically
return (always!) a wide_int_ptr kind. The initialization then would
use the assignment operator that mediates between wide_int and
wide_int_ptr, doing the copying.
The user should get a 'stack' kind by default when specifying wide_int,
like implemented with
struct wide_int_storage_stack;
struct wide_int_storage_ptr;
template class storage = wide_int_storage_stack
class wide_int : public storage
{
...
static wide_int wide_int_storage_ptr from_rtx (rtx);
}
the whole point of the exercise is to make from_rtx and from_tree avoid
the copying (and excessive stack space allocation) for the rvalue case
like in
wide_int res = wide_int::from_rtx (x) + 1;
if you save the result into a wide_int temporary first then you are lost
of course (modulo some magic GCC optimization being able to elide
the copy somehow).
And of course for code like VRP that keeps a lattice of wide_ints to
be able to reduce its footprint by using ptr storage and explicit allocations
(that's a secondary concern, of course). And for VRP to specify that
it needs more than the otherwise needed MAX_INT_MODE_SIZE.
ptr storage would not have this arbitrary limitation, only embedded
storage (should) have.
then when i want to call some function using a wide_int ref that function
now must be either overloaded to take both or i have to choose one of the
two instantiations (presumably based on which is going to be more common)
and just have the compiler fix up everything (which it is likely to do).
Nope, they'd be
class wide_int ...
{
template class storage1, class storage2
wide_int operator+(wide_int storage1 a, wide_intstorage2 b)
{
return wide_int::plus_worker (a.precision, a. , a.get_storage_ptr (),
b.precision, ...,
b.get_storage_ptr ());
}
And so what is the payoff:
1) No one except the c++ elite is going to understand the code. The rest of
the community will hate me and curse the ground that i walk on.
Maybe for the implementation - but look at hash-table and vec ... not for
usage certainly.
2) I will end up with a version of wide-int that can be used as a medium
life container (where i define medium life as not allowed to survive a gc
since they will contain pointers into rtxes and trees.)
3) An no clients that actually wanted to do this!!I could use as an
example one of your favorite passes, tree-vrp. The current double-int
could have been a medium lifetime container since it has a smaller
footprint, but in fact tree-vrp converts those double-ints back into trees
for medium storage. Why, because it needs the other fields of a tree-cst
to store the entire state. Wide-ints also suffer this problem. their
only state are the data, and the three length fields. They have no type
and none of the other tree info so the most obvious client for a medium
lifetime object is really not going to be a good match even if you solve
the storage problem.
The fact is that wide-ints are an excellent short term storage class that
can be very quickly converted into our two long term storage classes. Your
proposal is requires a lot of work, will not be easy to use and as far as i
can see has no payoff on the horizon. It could be that there could be
future clients for a medium lifetime value, but asking for this with no
clients in hand is really beyond the scope of a reasonable review.
I remind you that the purpose of these patches is to solve problems that
exist in the current compiler that we have papered over for years. If
someone needs wide-ints in some way that is not foreseen then they can
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
i will discuss this with mike when he wakes up.he lives on the west
pole so that will not be until after you go to bed.
the one point that i will take exception to is that the copying
operation is, in practice, any more time expensive than the pointer
copy. I never bother to initialize the storage in the array, i only
copy the elements that are live.This is with almost always 1 hwi
because either most types are small or most constants of large types
compress to 1 hwi.So even if a compilation does a zillion
::from_trees, you will most likely never see the difference in time.
kenny
On 11/27/2012 05:03 AM, Richard Biener wrote:
On Tue, Nov 27, 2012 at 1:06 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Richard,
I spent a good part of the afternoon talking to Mike about this. He is on
the c++ standards committee and is a much more seasoned c++ programmer than
I am.
He convinced me that with a large amount of engineering and c++
foolishness that it was indeed possible to get your proposal to POSSIBLY
work as well as what we did.
But now the question is why would any want to do this?
At the very least you are talking about instantiating two instances of
wide-ints, one for the stack allocated uses and one for the places where we
just move a pointer from the tree or the rtx. Then you are talking about
creating connectors so that the stack allocated functions can take
parameters of pointer version and visa versa.
Then there is the issue that rather than just saying that something is a
wide int, that the programmer is going to have to track it's origin. In
particular, where in the code right now i say.
wide_int foo = wide_int::from_rtx (r1);
wide_int bar = wide_int::from_rtx (r2) + foo;
now i would have to say
wide_int_ptr foo = wide_int_ptr::from_rtx (r1);
wide_int_stack bar = wide_int_ptr::from_rtx (r2) + foo;
No, you'd say
wide_int foo = wide_int::from_rtx (r1);
and the static, non-templated from_rtx method would automagically
return (always!) a wide_int_ptr kind. The initialization then would
use the assignment operator that mediates between wide_int and
wide_int_ptr, doing the copying.
The user should get a 'stack' kind by default when specifying wide_int,
like implemented with
struct wide_int_storage_stack;
struct wide_int_storage_ptr;
template class storage = wide_int_storage_stack
class wide_int : public storage
{
...
static wide_int wide_int_storage_ptr from_rtx (rtx);
}
the whole point of the exercise is to make from_rtx and from_tree avoid
the copying (and excessive stack space allocation) for the rvalue case
like in
wide_int res = wide_int::from_rtx (x) + 1;
if you save the result into a wide_int temporary first then you are lost
of course (modulo some magic GCC optimization being able to elide
the copy somehow).
And of course for code like VRP that keeps a lattice of wide_ints to
be able to reduce its footprint by using ptr storage and explicit allocations
(that's a secondary concern, of course). And for VRP to specify that
it needs more than the otherwise needed MAX_INT_MODE_SIZE.
ptr storage would not have this arbitrary limitation, only embedded
storage (should) have.
then when i want to call some function using a wide_int ref that function
now must be either overloaded to take both or i have to choose one of the
two instantiations (presumably based on which is going to be more common)
and just have the compiler fix up everything (which it is likely to do).
Nope, they'd be
class wide_int ...
{
template class storage1, class storage2
wide_int operator+(wide_int storage1 a, wide_intstorage2 b)
{
return wide_int::plus_worker (a.precision, a. , a.get_storage_ptr (),
b.precision, ...,
b.get_storage_ptr ());
}
And so what is the payoff:
1) No one except the c++ elite is going to understand the code. The rest of
the community will hate me and curse the ground that i walk on.
Maybe for the implementation - but look at hash-table and vec ... not for
usage certainly.
2) I will end up with a version of wide-int that can be used as a medium
life container (where i define medium life as not allowed to survive a gc
since they will contain pointers into rtxes and trees.)
3) An no clients that actually wanted to do this!!I could use as an
example one of your favorite passes, tree-vrp. The current double-int
could have been a medium lifetime container since it has a smaller
footprint, but in fact tree-vrp converts those double-ints back into trees
for medium storage. Why, because it needs the other fields of a tree-cst
to store the entire state. Wide-ints also suffer this problem. their
only state are the data, and the three length fields. They have no type
and none of the other tree info so the most obvious client for a medium
lifetime object is really not going to be a good match even if you solve
the storage problem.
The fact is that wide-ints are an
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Nov 5, 2012 at 2:59 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: On 11/04/2012 11:54 AM, Richard Biener wrote: On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford rdsandif...@googlemail.com wrote: Kenneth Zadeck zad...@naturalbridge.com writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I think richi's argument was that wide_int should be split into two. There should be a bare-metal class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo2 double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int class would still provide as wide as we need arithmetic, as in your rtl patch. I don't think he was objecting to that. That summarizes one part of my complaints / suggestions correctly. In other mails I suggested to not make it a template but a constant over object lifetime 'bitsize' (or maxlen) field. Both suggestions likely require more thought than I put into them. The main reason is that with C++ you can abstract from where wide-int information pieces are stored and thus use the arithmetic / operation workers without copying the (source) wide-int objects. Thus you should be able to write adaptors for double-int storage, tree or RTX storage. We had considered something along these lines and rejected it. I am not really opposed to doing something like this, but it is not an obvious winning idea and is likely not to be a good idea. Here was our thought process: if you abstract away the storage inside a wide int, then you should be able to copy a pointer to the block of data from either the rtl level integer constant or the tree level one into the wide int. It is certainly true that making a wide_int from one of these is an extremely common operation and doing this would avoid those copies. However, this causes two problems: 1) Mike's first cut at the CONST_WIDE_INT did two ggc allocations to make the object. it created the base object and then it allocated the array. Richard S noticed that we could just allocate one CONST_WIDE_INT that had the array in it. Doing it this way saves one ggc allocation and one indirection when accessing the data within the CONST_WIDE_INT. Our plan is to use the same trick at the tree level. So to avoid the copying, you seem to have to have a more expensive rep for CONST_WIDE_INT and INT_CST. I did not propose having a pointer to the data in the RTX or tree int. Just the short-lived wide-ints (which are on the stack) would have a pointer to the data - which can then obviously point into the RTX and tree data. 2) You are now stuck either ggcing the storage inside a wide_int when they are created as part of an expression or you have to play some game to represent the two different storage plans inside of wide_int. Hm? wide-ints are short-lived and thus never live across a garbage collection point. We create non-GCed objects pointing to GCed objects all the time and everywhere this way. Clearly this is where you think that we should be going by suggesting that we abstract away the internal storage. However, this comes at a price: what is currently an array access in my patches would (i believe) become a function call. No, the workers (that perform the array accesses) will simply get a pointer to the first data element. Then whether it's embedded or external is of no interest to them. From a performance point of view, i believe that this is a non starter. If you can figure out how to design this so that it is not a function call, i would consider this a viable option. On the other side of this you are clearly correct that we are copying the data when we are making wide ints from INT_CSTs or CONST_WIDE_INTs.But this is why we represent data inside of the wide_ints, the INT_CSTs and the CONST_WIDE_INTs in a compressed form. Even with very big types, which are
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 11/26/2012 10:03 AM, Richard Biener wrote: On Mon, Nov 5, 2012 at 2:59 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: On 11/04/2012 11:54 AM, Richard Biener wrote: On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford rdsandif...@googlemail.com wrote: Kenneth Zadeck zad...@naturalbridge.com writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I think richi's argument was that wide_int should be split into two. There should be a bare-metal class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo2 double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int class would still provide as wide as we need arithmetic, as in your rtl patch. I don't think he was objecting to that. That summarizes one part of my complaints / suggestions correctly. In other mails I suggested to not make it a template but a constant over object lifetime 'bitsize' (or maxlen) field. Both suggestions likely require more thought than I put into them. The main reason is that with C++ you can abstract from where wide-int information pieces are stored and thus use the arithmetic / operation workers without copying the (source) wide-int objects. Thus you should be able to write adaptors for double-int storage, tree or RTX storage. We had considered something along these lines and rejected it. I am not really opposed to doing something like this, but it is not an obvious winning idea and is likely not to be a good idea. Here was our thought process: if you abstract away the storage inside a wide int, then you should be able to copy a pointer to the block of data from either the rtl level integer constant or the tree level one into the wide int. It is certainly true that making a wide_int from one of these is an extremely common operation and doing this would avoid those copies. However, this causes two problems: 1) Mike's first cut at the CONST_WIDE_INT did two ggc allocations to make the object. it created the base object and then it allocated the array. Richard S noticed that we could just allocate one CONST_WIDE_INT that had the array in it. Doing it this way saves one ggc allocation and one indirection when accessing the data within the CONST_WIDE_INT. Our plan is to use the same trick at the tree level. So to avoid the copying, you seem to have to have a more expensive rep for CONST_WIDE_INT and INT_CST. I did not propose having a pointer to the data in the RTX or tree int. Just the short-lived wide-ints (which are on the stack) would have a pointer to the data - which can then obviously point into the RTX and tree data. There is the issue then what if some wide-ints are not short lived. It makes me nervous to create internal pointers to gc ed memory. 2) You are now stuck either ggcing the storage inside a wide_int when they are created as part of an expression or you have to play some game to represent the two different storage plans inside of wide_int. Hm? wide-ints are short-lived and thus never live across a garbage collection point. We create non-GCed objects pointing to GCed objects all the time and everywhere this way. Again, this makes me nervous but it could be done. However, it does mean that now the wide ints that are not created from rtxes or trees will be more expensive because they are not going to get their storage for free, they are going to alloca it. however, it still is not clear, given that 99% of the wide ints are going to fit in a single hwi, that this would be a noticeable win. Clearly this is where you think that we should be going by suggesting that we abstract away the internal storage. However, this comes at a price: what is currently an array access in my patches would (i believe) become a function call. No, the workers (that perform the array accesses) will simply get a pointer to the first data element. Then whether it's embedded or external is of no interest to
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Nov 26, 2012 at 5:03 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: On 11/26/2012 10:03 AM, Richard Biener wrote: On Mon, Nov 5, 2012 at 2:59 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: On 11/04/2012 11:54 AM, Richard Biener wrote: On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford rdsandif...@googlemail.com wrote: Kenneth Zadeck zad...@naturalbridge.com writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I think richi's argument was that wide_int should be split into two. There should be a bare-metal class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo2 double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int class would still provide as wide as we need arithmetic, as in your rtl patch. I don't think he was objecting to that. That summarizes one part of my complaints / suggestions correctly. In other mails I suggested to not make it a template but a constant over object lifetime 'bitsize' (or maxlen) field. Both suggestions likely require more thought than I put into them. The main reason is that with C++ you can abstract from where wide-int information pieces are stored and thus use the arithmetic / operation workers without copying the (source) wide-int objects. Thus you should be able to write adaptors for double-int storage, tree or RTX storage. We had considered something along these lines and rejected it. I am not really opposed to doing something like this, but it is not an obvious winning idea and is likely not to be a good idea. Here was our thought process: if you abstract away the storage inside a wide int, then you should be able to copy a pointer to the block of data from either the rtl level integer constant or the tree level one into the wide int. It is certainly true that making a wide_int from one of these is an extremely common operation and doing this would avoid those copies. However, this causes two problems: 1) Mike's first cut at the CONST_WIDE_INT did two ggc allocations to make the object. it created the base object and then it allocated the array. Richard S noticed that we could just allocate one CONST_WIDE_INT that had the array in it. Doing it this way saves one ggc allocation and one indirection when accessing the data within the CONST_WIDE_INT. Our plan is to use the same trick at the tree level. So to avoid the copying, you seem to have to have a more expensive rep for CONST_WIDE_INT and INT_CST. I did not propose having a pointer to the data in the RTX or tree int. Just the short-lived wide-ints (which are on the stack) would have a pointer to the data - which can then obviously point into the RTX and tree data. There is the issue then what if some wide-ints are not short lived. It makes me nervous to create internal pointers to gc ed memory. I thought they were all short-lived. 2) You are now stuck either ggcing the storage inside a wide_int when they are created as part of an expression or you have to play some game to represent the two different storage plans inside of wide_int. Hm? wide-ints are short-lived and thus never live across a garbage collection point. We create non-GCed objects pointing to GCed objects all the time and everywhere this way. Again, this makes me nervous but it could be done. However, it does mean that now the wide ints that are not created from rtxes or trees will be more expensive because they are not going to get their storage for free, they are going to alloca it. No, those would simply use the embedded storage model. however, it still is not clear, given that 99% of the wide ints are going to fit in a single hwi, that this would be a noticeable win. Currently even if they fit into a HWI you will still allocate 4 times the larges integer mode size. You say that doesn't matter because they are
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Richard, I spent a good part of the afternoon talking to Mike about this. He is on the c++ standards committee and is a much more seasoned c++ programmer than I am. He convinced me that with a large amount of engineering and c++ foolishness that it was indeed possible to get your proposal to POSSIBLY work as well as what we did. But now the question is why would any want to do this? At the very least you are talking about instantiating two instances of wide-ints, one for the stack allocated uses and one for the places where we just move a pointer from the tree or the rtx. Then you are talking about creating connectors so that the stack allocated functions can take parameters of pointer version and visa versa. Then there is the issue that rather than just saying that something is a wide int, that the programmer is going to have to track it's origin. In particular, where in the code right now i say. wide_int foo = wide_int::from_rtx (r1); wide_int bar = wide_int::from_rtx (r2) + foo; now i would have to say wide_int_ptr foo = wide_int_ptr::from_rtx (r1); wide_int_stack bar = wide_int_ptr::from_rtx (r2) + foo; then when i want to call some function using a wide_int ref that function now must be either overloaded to take both or i have to choose one of the two instantiations (presumably based on which is going to be more common) and just have the compiler fix up everything (which it is likely to do). And so what is the payoff: 1) No one except the c++ elite is going to understand the code. The rest of the community will hate me and curse the ground that i walk on. 2) I will end up with a version of wide-int that can be used as a medium life container (where i define medium life as not allowed to survive a gc since they will contain pointers into rtxes and trees.) 3) An no clients that actually wanted to do this!!I could use as an example one of your favorite passes, tree-vrp. The current double-int could have been a medium lifetime container since it has a smaller footprint, but in fact tree-vrp converts those double-ints back into trees for medium storage. Why, because it needs the other fields of a tree-cst to store the entire state. Wide-ints also suffer this problem. their only state are the data, and the three length fields. They have no type and none of the other tree info so the most obvious client for a medium lifetime object is really not going to be a good match even if you solve the storage problem. The fact is that wide-ints are an excellent short term storage class that can be very quickly converted into our two long term storage classes. Your proposal is requires a lot of work, will not be easy to use and as far as i can see has no payoff on the horizon. It could be that there could be future clients for a medium lifetime value, but asking for this with no clients in hand is really beyond the scope of a reasonable review. I remind you that the purpose of these patches is to solve problems that exist in the current compiler that we have papered over for years. If someone needs wide-ints in some way that is not foreseen then they can change it. kenny On 11/26/2012 11:30 AM, Richard Biener wrote: On Mon, Nov 26, 2012 at 5:03 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: On 11/26/2012 10:03 AM, Richard Biener wrote: On Mon, Nov 5, 2012 at 2:59 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: On 11/04/2012 11:54 AM, Richard Biener wrote: On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford rdsandif...@googlemail.com wrote: Kenneth Zadeck zad...@naturalbridge.com writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I think richi's argument was that wide_int should be split into two. There should be a bare-metal class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo2 double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, 2012-10-29 at 18:56 +0100, Jakub Jelinek wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. I'd like to post later today (hopefully this morning) a very minimal configure patch that adds the -mcpu=power8 and -mtune=power8 compiler options to gcc. Currently, power8 will be an alias for power7, but getting this path in now allows us to add power8 support to the compiler without having to touch the arch independent configure script. The only hang up at the moment is we're still determining the assembler mnemonic we'll be releasing that the gcc configure script will use to test for power6 assembler support. Peter
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Nov 05, 2012 at 06:41:47AM -0600, Peter Bergner wrote: On Mon, 2012-10-29 at 18:56 +0100, Jakub Jelinek wrote: I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. I'd like to post later today (hopefully this morning) a very minimal configure patch that adds the -mcpu=power8 and -mtune=power8 compiler options to gcc. Currently, power8 will be an alias for power7, but getting this path in now allows us to add power8 support to the compiler without having to touch the arch independent configure script. config.gcc target specific hunks are part of the backend, the individual target maintainers can approve changes to that, I really don't see a reason to add a dummy alias now just for that. If the power8 enablement is approved and non-intrusive enough that it would be acceptable even during stage 3, then so would be corresponding config.gcc changes. Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 11/04/2012 11:54 AM, Richard Biener wrote: On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford rdsandif...@googlemail.com wrote: Kenneth Zadeck zad...@naturalbridge.com writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I think richi's argument was that wide_int should be split into two. There should be a bare-metal class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo2 double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int class would still provide as wide as we need arithmetic, as in your rtl patch. I don't think he was objecting to that. That summarizes one part of my complaints / suggestions correctly. In other mails I suggested to not make it a template but a constant over object lifetime 'bitsize' (or maxlen) field. Both suggestions likely require more thought than I put into them. The main reason is that with C++ you can abstract from where wide-int information pieces are stored and thus use the arithmetic / operation workers without copying the (source) wide-int objects. Thus you should be able to write adaptors for double-int storage, tree or RTX storage. We had considered something along these lines and rejected it. I am not really opposed to doing something like this, but it is not an obvious winning idea and is likely not to be a good idea. Here was our thought process: if you abstract away the storage inside a wide int, then you should be able to copy a pointer to the block of data from either the rtl level integer constant or the tree level one into the wide int. It is certainly true that making a wide_int from one of these is an extremely common operation and doing this would avoid those copies. However, this causes two problems: 1) Mike's first cut at the CONST_WIDE_INT did two ggc allocations to make the object. it created the base object and then it allocated the array. Richard S noticed that we could just allocate one CONST_WIDE_INT that had the array in it. Doing it this way saves one ggc allocation and one indirection when accessing the data within the CONST_WIDE_INT. Our plan is to use the same trick at the tree level. So to avoid the copying, you seem to have to have a more expensive rep for CONST_WIDE_INT and INT_CST. 2) You are now stuck either ggcing the storage inside a wide_int when they are created as part of an expression or you have to play some game to represent the two different storage plans inside of wide_int. Clearly this is where you think that we should be going by suggesting that we abstract away the internal storage. However, this comes at a price: what is currently an array access in my patches would (i believe) become a function call. From a performance point of view, i believe that this is a non starter. If you can figure out how to design this so that it is not a function call, i would consider this a viable option. On the other side of this you are clearly correct that we are copying the data when we are making wide ints from INT_CSTs or CONST_WIDE_INTs. But this is why we represent data inside of the wide_ints, the INT_CSTs and the CONST_WIDE_INTs in a compressed form. Even with very big types, which are generally rare, the constants them selves are very small. So the copy operation is a loop that almost always copies one element, even with tree-vrp which doubles the sizes of every type. There is the third option which is that the storage inside the wide int is just ggced storage. We rejected this because of the functional nature of wide-ints.There are zillions created, they can be stack allocated, and they last for very short periods of time. As is probably obvious, I don't agree FWIW. It seems like an unnecessary complication without any clear use. Especially since the number of Maybe the double_int typedef is without any clear use. Properly abstracting from the
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, 2012-11-05 at 13:53 +0100, Jakub Jelinek wrote: On Mon, Nov 05, 2012 at 06:41:47AM -0600, Peter Bergner wrote: I'd like to post later today (hopefully this morning) a very minimal configure patch that adds the -mcpu=power8 and -mtune=power8 compiler options to gcc. Currently, power8 will be an alias for power7, but getting this path in now allows us to add power8 support to the compiler without having to touch the arch independent configure script. config.gcc target specific hunks are part of the backend, the individual target maintainers can approve changes to that, I really don't see a reason to add a dummy alias now just for that. If the power8 enablement is approved and non-intrusive enough that it would be acceptable even during stage 3, then so would be corresponding config.gcc changes. Well we also patch config.in and configure.ac/configure. If those are acceptable to be patched later too, then great. If not, the patch isn't really very large. We did do this for power7 initially too: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00162.html Peter
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Nov 05, 2012 at 08:40:00AM -0600, Peter Bergner wrote: Well we also patch config.in and configure.ac/configure. If those are acceptable to be patched later too, then great. If not, the patch That is the same thing as config.gcc bits. isn't really very large. We did do this for power7 initially too: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00162.html But then power7 patch went in during stage1 of the n+1 release, and wasn't really backported to release branch (just to distro vendor branches), right? Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Wed, 2012-10-31 at 11:13 +0100, Richard Biener wrote: On Mon, Oct 29, 2012 at 6:56 PM, Jakub Jelinek ja...@redhat.com wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Reminds me of the stable plugin API for introspection. David, Micha - what's the status here? Adding this is certainly ok during stage3 and I think that we should have something in 4.8 to kick of further development here. (sorry for the belated response, I was on vacation). I'm currently leaning towards having the API as a separate source tree that can be compiled against 4.6 through 4.8 onwards (hiding all necessary compatibility cruft within it [1]), generating a library that plugins can link against, providing a consistent C API across all of these GCC versions. Keeping it out-of-tree allows plugins to be written that can work with older versions of gcc, and allows the plugin API to change more rapidly than the rest of gcc (especially important for these older gcc releases). Distributions of gcc could build the plugin api at the same time as gcc, albeit from a separate tarball. When the API is more mature, we could merge it inside gcc proper, I guess. I'll try to post something later today. Dave [1] e.g C vs C++ linkage
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Jakub and Richi, At this point I have decided to that i am not going to get the rest of the wide-int patches into a stable enough form for this round. The combination of still living without power at my house and some issues that i hit with the front ends has made it impossible to get this finished by today's deadline. I do want patches 1-7 to go in (after proper review) but i am going to withdraw patch 8 for this round. patches 1-5 deal with the rtl level. These have been extensively tested and examined with the exception of patch 4, examined by Richard Sandiford.They clean up a lot of things at the rtl level that effect every port as well as fixing some outstanding regressions. patches 6 and 7 are general cleanups at the tree level and can be justified as on their own without any regard to wide-int.They have also been extensively tested. I am withdrawing patch 8 because it converted tree-vpn to use wide-ints but the benefit of this patch really cannot be seen without the rest of the tree level wide-int patches. In the next couple of days i will resubmit patches 1-7 with the patch rot removed and the public comments folded into them. Kenny
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
I'd like to get a small patch to tree reassociation ( http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01761.html ) in. Thanks, Easwaran On Mon, Oct 29, 2012 at 10:56 AM, Jakub Jelinek ja...@redhat.com wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Quality Data Priority # Change from Last Report --- --- P1 23 + 23 P2 77 + 8 P3 85 + 84 --- --- Total 185 +115 Previous Report === http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html The next report will be sent by me again, announcing end of stage 1.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, 2012-11-05 at 15:47 +0100, Jakub Jelinek wrote: On Mon, Nov 05, 2012 at 08:40:00AM -0600, Peter Bergner wrote: Well we also patch config.in and configure.ac/configure. If those are acceptable to be patched later too, then great. If not, the patch That is the same thing as config.gcc bits. isn't really very large. We did do this for power7 initially too: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00162.html But then power7 patch went in during stage1 of the n+1 release, and wasn't really backported to release branch (just to distro vendor branches), right? I think we could have done better there, yes, but not all of our patches were appropriate for backporting, especially those parts that touched outside of the port. There will be portions of power8 we won't/don't want to backport either, but I would like to get the major backend portions like machine description files and the like backported to 4.8 when the time comes. Having the configurey changes in would help that, but if you say those are things we can get in after stage1, then that can ease things a bit. That said, I'll post our current patch as is and discuss within our team and with David on what our next course of action should be. Peter
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford rdsandif...@googlemail.com wrote: Kenneth Zadeck zad...@naturalbridge.com writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I think richi's argument was that wide_int should be split into two. There should be a bare-metal class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo2 double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int class would still provide as wide as we need arithmetic, as in your rtl patch. I don't think he was objecting to that. That summarizes one part of my complaints / suggestions correctly. In other mails I suggested to not make it a template but a constant over object lifetime 'bitsize' (or maxlen) field. Both suggestions likely require more thought than I put into them. The main reason is that with C++ you can abstract from where wide-int information pieces are stored and thus use the arithmetic / operation workers without copying the (source) wide-int objects. Thus you should be able to write adaptors for double-int storage, tree or RTX storage. As is probably obvious, I don't agree FWIW. It seems like an unnecessary complication without any clear use. Especially since the number of Maybe the double_int typedef is without any clear use. Properly abstracting from the storage / information providers will save compile-time, memory and code though. I don't see that any thought was spent on how to avoid excessive copying or dealing with long(er)-lived objects and their storage needs. significant HWIs in a wide_int isn't always going to be the same for both operands to a binary operation, and it's not clear to me whether that should be handled in the base class or wide_int. It certainly depends. Richard. Richard
[wwwdocs] PATCH for Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, 29 Oct 2012, Jakub Jelinek wrote: I'd like to close the stage 1 phase of GCC 4.8 development Documented via the patch below. I also changed Active Development to Development to reduce text density and improve formatting on a wider range of window/text sizes. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.863 diff -u -3 -p -r1.863 index.html --- index.html 20 Sep 2012 15:35:43 - 1.863 +++ index.html 2 Nov 2012 22:48:54 - @@ -171,12 +171,12 @@ Any additions? Don't be shy, send them /span /dd -dtspan class=versionActive development:/span +dtspan class=versionDevelopment:/span GCC 4.8.0 (a href=gcc-4.8/changes.htmlchanges/a, a href=gcc-4.8/criteria.htmlrelease criteria/a) /dtdd Status: !--GCC 4.8 status below-- - a href=http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html;2012-03-02/a + a href=http://gcc.gnu.org/ml/gcc/2012-10/msg00434.html;2012-10-29/a !--GCC 4.8 status above-- (general development, stage 1). br /
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Tue, Oct 30, 2012 at 4:04 PM, Sharad Singhai sing...@google.com wrote: Hi Jakub, My -fopt-info pass filtering patch (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02704.html) is being reviewed and I hope to get this in by Nov. 5 for inclusion in gcc 4.8.0. I just committed -fopt-info pass filtering patch as r193061. Thanks, Sharad Thanks, Sharad On Mon, Oct 29, 2012 at 10:56 AM, Jakub Jelinek ja...@redhat.com wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Quality Data Priority # Change from Last Report --- --- P1 23 + 23 P2 77 + 8 P3 85 + 84 --- --- Total 185 +115 Previous Report === http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html The next report will be sent by me again, announcing end of stage 1.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Thu, Nov 01, 2012 at 12:52:04AM -0700, Sharad Singhai wrote: On Tue, Oct 30, 2012 at 4:04 PM, Sharad Singhai sing...@google.com wrote: Hi Jakub, My -fopt-info pass filtering patch (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02704.html) is being reviewed and I hope to get this in by Nov. 5 for inclusion in gcc 4.8.0. I just committed -fopt-info pass filtering patch as r193061. How was that change tested? I'm seeing thousands of new UNRESOLVED failures, of the form: spawn -ignore SIGHUP /usr/src/gcc/obj415/gcc/xgcc -B/usr/src/gcc/obj415/gcc/ /usr/src/gcc/gcc/testsuite/gcc.target/i386/branch-cost1.c -fno-diagnostics-show-caret -O2 -fdump-tree-gimple -mbranch-cost=0 -S -o branch-cost1.s PASS: gcc.target/i386/branch-cost1.c (test for excess errors) gcc.target/i386/branch-cost1.c: dump file does not exist UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-times gimple if 2 gcc.target/i386/branch-cost1.c: dump file does not exist UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-not gimple See http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00033.html or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00034.html, compare that to http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00025.html or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00026.html The difference is just your patch and unrelated sh backend change. Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
richi, I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I would like to point out that there are about 125 places where we have two copies of the code for some operation. Many of these places are smaller than this, but some are larger. There are also at least several hundred places where the code only was written for the 1 hwi case. These are harder to find with simple greps. I am very concerned about this particular aspect of your comments because it seems to doom us to write the same code over and over again. kenny On 10/31/2012 02:19 PM, Kenneth Zadeck wrote: Jakub, it is hard from all of the threads to actually distill what the real issues are here. So let me start from a clean slate and state them simply. Richi has three primary objections: 1) that we can do all of this with a templated version of double-int. 2) that we should not be passing in a precision and bitsize into the interface. 3) that the interface is too large. I have attached a fragment of my patch #5 to illustrate the main thrust of my patches and to illustrate the usefulness to gcc right now. In the current trunk, we have code that does simplification when the mode fits in an HWI and we have code that does the simplification if the mode fits in two HWIs. if the mode does not fit in two hwi's the code does not do the simplification. Thus here and in a large number of other places we have two copies of the code.Richi wants there to be multiple template instantiations of double-int.This means that we are now going to have to have 3 copies of this code to support oi mode on a 64 bit host and 4 copies on a 32 bit host. Further note that there are not as many cases for the 2*hwi in the code as their are for the hwi case and in general this is true through out the compiler. (CLRSB is missing from the 2hwi case in the patch) We really did not write twice the code when we stated supporting 2 hwi, we added about 1.5 times the code (simplify-rtx is better than most of the rest of the compiler). I am using the rtl level as an example here because i have posted all of those patches, but the tree level is no better. I do not want to write this code a third time and certainly not a fourth time. Just fixing all of this is quite useful now: it fills in a lot of gaps in our transformations and it removes many edge case crashes because ti mode really is lightly tested. However, this patch becomes crucial as the world gets larger. Richi's second point is that we should be doing everything at infinite precision and not passing in an explicit bitsize and precision. That works ok (sans the issues i raised with it in tree-vpn earlier) when the largest precision on the machine fits in a couple of hwis.However, for targets that have large integers or cross compilers, this becomes expensive.The idea behind my set of patches is that for the transformations that can work this way, we do the math in the precision of the type or mode. In general this means that almost all of the math will be done quickly, even on targets that support really big integers. For passes like tree-vrp, the math will be done at some multiple of the largest type seen in the actual program.The amount of the multiple is a function of the optimization, not the target or the host. Currently (on my home computer) the wide-int interface allows the optimization to go 4x the largest mode on the target. I can get rid of this bound at the expense of doing an alloca rather than stack allocating a fixed sized structure.However, given the extremely heavy use of this interface, that does not seem like the best of tradeoffs. The truth is that the vast majority of the compiler actually wants to see the math done the way that it is going to be done on the machine. Tree-vrp and the gimple constant prop do not. But i have made accommodations to handle both needs.I believe that the reason that double-int was never used at the rtl level is that it does not actually do the math in a way that is useful to the target. Richi's third objection is that the interface is too large. I disagree. It was designed based on the actual usage of the interface. When i found places where i was
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Thu, Nov 1, 2012 at 8:28 AM, Jakub Jelinek ja...@redhat.com wrote: How was that change tested? I'm seeing thousands of new UNRESOLVED failures, of the form: spawn -ignore SIGHUP /usr/src/gcc/obj415/gcc/xgcc -B/usr/src/gcc/obj415/gcc/ /usr/src/gcc/gcc/testsuite/gcc.target/i386/branch-cost1.c -fno-diagnostics-show-caret -O2 -fdump-tree-gimple -mbranch-cost=0 -S -o branch-cost1.s PASS: gcc.target/i386/branch-cost1.c (test for excess errors) gcc.target/i386/branch-cost1.c: dump file does not exist UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-times gimple if 2 gcc.target/i386/branch-cost1.c: dump file does not exist UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-not gimple See http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00033.html or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00034.html, compare that to http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00025.html or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00026.html The difference is just your patch and unrelated sh backend change. I'm seeing the same failures. Sharad, could you fix them or revert your change? Thanks. Diego.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Kenneth Zadeck zad...@naturalbridge.com writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I think richi's argument was that wide_int should be split into two. There should be a bare-metal class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo2 double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int class would still provide as wide as we need arithmetic, as in your rtl patch. I don't think he was objecting to that. As is probably obvious, I don't agree FWIW. It seems like an unnecessary complication without any clear use. Especially since the number of significant HWIs in a wide_int isn't always going to be the same for both operands to a binary operation, and it's not clear to me whether that should be handled in the base class or wide_int. Richard
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 11/01/2012 09:10 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
I would like you to respond to at least point 1 of this email. In it
there is code from the rtl level that was written twice, once for the
case when the size of the mode is less than the size of a HWI and once
for the case where the size of the mode is less that 2 HWIs.
my patch changes this to one instance of the code that works no matter
how large the data passed to it is.
you have made a specific requirement for wide int to be a template that
can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I
would like to know how this particular fragment is to be rewritten in
this model? It seems that I would have to retain the structure where
there is one version of the code for each size that the template is
instantiated.
I think richi's argument was that wide_int should be split into two.
There should be a bare-metal class that just has a length and HWIs,
and the main wide_int class should be an extension on top of that
that does things to a bit precision instead. Presumably with some
template magic so that the length (number of HWIs) is a constant for:
typedef foo2 double_int;
and a variable for wide_int (because in wide_int the length would be
the number of significant HWIs rather than the size of the underlying
array). wide_int would also record the precision and apply it after
the full HWI operation.
So the wide_int class would still provide as wide as we need arithmetic,
as in your rtl patch. I don't think he was objecting to that.
As is probably obvious, I don't agree FWIW. It seems like an unnecessary
complication without any clear use. Especially since the number of
significant HWIs in a wide_int isn't always going to be the same for
both operands to a binary operation, and it's not clear to me whether
that should be handled in the base class or wide_int.
Richard
There is a certain amount of surprise about all of this on my part.I
thought that i was doing such a great thing by looking at the specific
port that you are building to determine how to size these data
structures.You would think from the response that i am getting that
i had murdered some one.
do you think that when he gets around to reading the patch for
simplify-rtx.c that he is going to object to this frag?
@@ -5179,13 +4815,11 @@ static rtx
simplify_immed_subreg (enum machine_mode outermode, rtx op,
enum machine_mode innermode, unsigned int byte)
{
- /* We support up to 512-bit values (for V8DFmode). */
enum {
-max_bitsize = 512,
value_bit = 8,
value_mask = (1 value_bit) - 1
};
- unsigned char value[max_bitsize / value_bit];
+ unsigned char value [MAX_BITSIZE_MODE_ANY_MODE/value_bit];
int value_start;
int i;
int elem;
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
anyway richard, it does not answer the question as to what you are going to do with a typedef foo2. the point of all of this work by me was to leave no traces of the host in the way the compiler works. instantiating a specific size of the double-ints is not going to get you there. kenny On 11/01/2012 09:10 AM, Richard Sandiford wrote: Kenneth Zadeck zad...@naturalbridge.com writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I think richi's argument was that wide_int should be split into two. There should be a bare-metal class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo2 double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int class would still provide as wide as we need arithmetic, as in your rtl patch. I don't think he was objecting to that. As is probably obvious, I don't agree FWIW. It seems like an unnecessary complication without any clear use. Especially since the number of significant HWIs in a wide_int isn't always going to be the same for both operands to a binary operation, and it's not clear to me whether that should be handled in the base class or wide_int. Richard
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
I am really sorry about that. I am looking and will fix the breakage or revert the patch shortly. Thanks, Sharad On Thu, Nov 1, 2012 at 5:28 AM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Nov 01, 2012 at 12:52:04AM -0700, Sharad Singhai wrote: On Tue, Oct 30, 2012 at 4:04 PM, Sharad Singhai sing...@google.com wrote: Hi Jakub, My -fopt-info pass filtering patch (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02704.html) is being reviewed and I hope to get this in by Nov. 5 for inclusion in gcc 4.8.0. I just committed -fopt-info pass filtering patch as r193061. How was that change tested? I'm seeing thousands of new UNRESOLVED failures, of the form: spawn -ignore SIGHUP /usr/src/gcc/obj415/gcc/xgcc -B/usr/src/gcc/obj415/gcc/ /usr/src/gcc/gcc/testsuite/gcc.target/i386/branch-cost1.c -fno-diagnostics-show-caret -O2 -fdump-tree-gimple -mbranch-cost=0 -S -o branch-cost1.s PASS: gcc.target/i386/branch-cost1.c (test for excess errors) gcc.target/i386/branch-cost1.c: dump file does not exist UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-times gimple if 2 gcc.target/i386/branch-cost1.c: dump file does not exist UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-not gimple See http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00033.html or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00034.html, compare that to http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00025.html or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00026.html The difference is just your patch and unrelated sh backend change. Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Richard Sandiford rdsandif...@googlemail.com writes: As is probably obvious, I don't agree FWIW. It seems like an unnecessary complication without any clear use. Especially since the number of significant HWIs in a wide_int isn't always going to be the same for both operands to a binary operation, and it's not clear to me whether that should be handled in the base class or wide_int. ...and the number of HWIs in the result might be different again. Whether that's true depends on the value as well as the (HWI) size of the operands. Richard
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Thu, Nov 1, 2012 at 12:40 PM, Sharad Singhai sing...@google.com wrote: I found the problem and the following patch fixes it. The issue with my testing was that I was only looking at 'FAIL' lines but forgot to tally the 'UNRESOLVED' test cases, the real symptoms of my test problems. In any case, I am rerunning the whole testsuite just to be sure. Assuming tests pass, is it okay to commit the following? Thanks, Sharad 2012-11-01 Sharad Singhai sing...@google.com PR other/55164 * dumpfile.h (struct dump_file_info): Fix order of flags. OK (remember to insert a tab at the start of each ChangeLog line). Diego.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Thu, Nov 1, 2012 at 9:44 AM, Diego Novillo dnovi...@google.com wrote: On Thu, Nov 1, 2012 at 12:40 PM, Sharad Singhai sing...@google.com wrote: I found the problem and the following patch fixes it. The issue with my testing was that I was only looking at 'FAIL' lines but forgot to tally the 'UNRESOLVED' test cases, the real symptoms of my test problems. In any case, I am rerunning the whole testsuite just to be sure. Assuming tests pass, is it okay to commit the following? Thanks, Sharad 2012-11-01 Sharad Singhai sing...@google.com PR other/55164 * dumpfile.h (struct dump_file_info): Fix order of flags. OK (remember to insert a tab at the start of each ChangeLog line). Fixed tab chars. (they were really there, but gmail ate them! :)) Retested and found all my 'UNRESOLVED' problems were gone. Hence committed the fix as r193064. Thanks, Sharad Diego.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Hi Jakub, I would like to get the fission implementation in before stage 1. It has been under review for some time, and is awaiting another round of review now. More info here: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02684.html Sterling
RE: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
-Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek Sent: Tuesday, October 30, 2012 1:57 AM To: g...@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org Subject: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Quality Data Priority # Change from Last Report --- --- P1 23 + 23 P2 77 + 8 P3 85 + 84 --- --- Total 185 +115 Previous Report === http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html The next report will be sent by me again, announcing end of stage 1. Hi, I am working on register pressure directed hoist pass and have committed the main patch in trunk. Here I still have two patches in this area improving it. I will send these two patches recently and hope it can be included in 4.8 if OK. Thanks.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: jakub, i am hoping to get the rest of my wide integer conversion posted by nov 5. I am under some adverse conditions here: hurricane sandy hit her pretty badly. my house is hooked up to a small generator, and no one has any power for miles around. So far richi has promised to review them. he has sent some comments, but so far no reviews.Some time after i get the first round of them posted, i will do a second round that incorporates everyones comments. But i would like a little slack here if possible.While this work is a show stopper for my private port, the patches address serious problems for many of the public ports, especially ones that have very flexible vector units.I believe that there are significant set of latent problems currently with the existing ports that use ti mode that these patches will fix. However, i will do everything in my power to get the first round of the patches posted by nov 5 deadline. I suppose you are not going to merge your private port for 4.8 and thus the wide-int changes are not a show-stopper for you. That said, I considered the main conversion to be appropriate to be defered for the next stage1. There is no advantage in disrupting the tree more at this stage. Thanks, Richard. kenny On 10/29/2012 01:56 PM, Jakub Jelinek wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Quality Data Priority # Change from Last Report --- --- P1 23 + 23 P2 77 + 8 P3 85 + 84 --- --- Total 185 +115 Previous Report === http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html The next report will be sent by me again, announcing end of stage 1.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Richard Biener richard.guent...@gmail.com writes: On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: jakub, i am hoping to get the rest of my wide integer conversion posted by nov 5. I am under some adverse conditions here: hurricane sandy hit her pretty badly. my house is hooked up to a small generator, and no one has any power for miles around. So far richi has promised to review them. he has sent some comments, but so far no reviews.Some time after i get the first round of them posted, i will do a second round that incorporates everyones comments. But i would like a little slack here if possible.While this work is a show stopper for my private port, the patches address serious problems for many of the public ports, especially ones that have very flexible vector units.I believe that there are significant set of latent problems currently with the existing ports that use ti mode that these patches will fix. However, i will do everything in my power to get the first round of the patches posted by nov 5 deadline. I suppose you are not going to merge your private port for 4.8 and thus the wide-int changes are not a show-stopper for you. That said, I considered the main conversion to be appropriate to be defered for the next stage1. There is no advantage in disrupting the tree more at this stage. I would like the wide_int class and rtl stuff to go in 4.8 though. IMO it's a significant improvement in its own right, and Kenny submitted it well before the deadline. Richard
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Wed, Oct 31, 2012 at 10:59 AM, Richard Sandiford rdsandif...@googlemail.com wrote: Richard Biener richard.guent...@gmail.com writes: On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: jakub, i am hoping to get the rest of my wide integer conversion posted by nov 5. I am under some adverse conditions here: hurricane sandy hit her pretty badly. my house is hooked up to a small generator, and no one has any power for miles around. So far richi has promised to review them. he has sent some comments, but so far no reviews.Some time after i get the first round of them posted, i will do a second round that incorporates everyones comments. But i would like a little slack here if possible.While this work is a show stopper for my private port, the patches address serious problems for many of the public ports, especially ones that have very flexible vector units.I believe that there are significant set of latent problems currently with the existing ports that use ti mode that these patches will fix. However, i will do everything in my power to get the first round of the patches posted by nov 5 deadline. I suppose you are not going to merge your private port for 4.8 and thus the wide-int changes are not a show-stopper for you. That said, I considered the main conversion to be appropriate to be defered for the next stage1. There is no advantage in disrupting the tree more at this stage. I would like the wide_int class and rtl stuff to go in 4.8 though. IMO it's a significant improvement in its own right, and Kenny submitted it well before the deadline. If it gets in as-is then we'll have to live with the IMHO broken API (yet another one besides the existing double-int). So _please_ shrink the API down aggresively in favor of using non-member helper functions with more descriptive names for things that lump together multiple operations. Look at double-int and use the same API ideas as people are familiar with it (like the unsigned flag stuff) - consistency always trumps. I'm going to be on vacation for the next three weeks so somebody else has to pick up the review work. But I really think that the tree has to recover from too many changes already. Richard.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Oct 29, 2012 at 6:56 PM, Jakub Jelinek ja...@redhat.com wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Reminds me of the stable plugin API for introspection. David, Micha - what's the status here? Adding this is certainly ok during stage3 and I think that we should have something in 4.8 to kick of further development here. Richard.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 10/30/2012 01:56, Jakub Jelinek wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Somebody with commit rights please push [Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from mingw32-w64/os_defines.h. Kai has already approved, but is off for the week. signature.asc Description: OpenPGP digital signature
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Wed, Oct 31, 2012 at 06:25:45PM +0800, JonY wrote: On 10/30/2012 01:56, Jakub Jelinek wrote: I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Somebody with commit rights please push [Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from mingw32-w64/os_defines.h. Kai has already approved, but is off for the week. That looks like a bugfix (or even regression bugfix). Bugfixes are fine through stage 3, regression bugfixes are fine even in stage 4. Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 31 October 2012 10:25, JonY wrote: On 10/30/2012 01:56, Jakub Jelinek wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Somebody with commit rights please push [Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from mingw32-w64/os_defines.h. Kai has already approved, but is off for the week. I could have done that, if it had been sent to the right lists. All libstdc++ patches go to both gcc-patches and libstd...@gcc.gnu.org please. Let's move this to the libstdc++ list, I have some questions about the patch.
[Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from (was Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon)
On 31 October 2012 11:01, Jonathan Wakely wrote: On 31 October 2012 10:25, JonY wrote: On 10/30/2012 01:56, Jakub Jelinek wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Somebody with commit rights please push [Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from mingw32-w64/os_defines.h. Kai has already approved, but is off for the week. I could have done that, if it had been sent to the right lists. All libstdc++ patches go to both gcc-patches and libstd...@gcc.gnu.org please. Let's move this to the libstdc++ list, I have some questions about the patch. It looks like the workaround is in mingw not in GCC, so is it a problem that it won't be possible to use GCC 4.8 with existing mingw versions, or are users required to use a brand new mingw to use a new GCC? Should that be documented in http://gcc.gnu.org/gcc-4.8/changes.html ? Why is the define commented out by the patch, not simply removed? If it's not needed then it's not needed. We have subversion to track change history, we don't need to leave dead code lying around with comments explaining why it's dead.
Re: [Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from (was Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon)
On 10/31/2012 19:12, Jonathan Wakely wrote: On 31 October 2012 11:01, Jonathan Wakely wrote: On 31 October 2012 10:25, JonY wrote: On 10/30/2012 01:56, Jakub Jelinek wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Somebody with commit rights please push [Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from mingw32-w64/os_defines.h. Kai has already approved, but is off for the week. I could have done that, if it had been sent to the right lists. All libstdc++ patches go to both gcc-patches and libstd...@gcc.gnu.org please. Let's move this to the libstdc++ list, I have some questions about the patch. It looks like the workaround is in mingw not in GCC, so is it a problem that it won't be possible to use GCC 4.8 with existing mingw versions, or are users required to use a brand new mingw to use a new GCC? Should that be documented in http://gcc.gnu.org/gcc-4.8/changes.html ? They are required to use the latest mingw-w64, the problem was that the vfswprintf that libstdc++ expects isn't the same as the one MS provides, so I've wrote a redirector to use the vsnwprintf, more precisely, the mingw C99 compliant __mingw_vsnwprintf. std::to_wstring and std::to_string work according to some simple tests. I guess the current comment about require mingw-w64 trunk at least r5437 is OK for the changes page. It should probably note that this change is mingw-w64 specific, with w64 as the vendor key. Why is the define commented out by the patch, not simply removed? If it's not needed then it's not needed. We have subversion to track change history, we don't need to leave dead code lying around with comments explaining why it's dead. OK, I will remove it. signature.asc Description: OpenPGP digital signature
Re: [Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from (was Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon)
On 10/31/2012 19:23, JonY wrote: Why is the define commented out by the patch, not simply removed? If it's not needed then it's not needed. We have subversion to track change history, we don't need to leave dead code lying around with comments explaining why it's dead. OK, I will remove it. Sorry, forgot to attach the patch. ChangeLog 2012-10-31 Jonathan Yong jo...@users.sourceforge.net * config/os/mingw32-w64/os_defines.h: Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF as no longer required. Index: libstdc++-v3/config/os/mingw32-w64/os_defines.h === --- libstdc++-v3/config/os/mingw32-w64/os_defines.h (revision 192802) +++ libstdc++-v3/config/os/mingw32-w64/os_defines.h (working copy) @@ -63,9 +63,6 @@ // See libstdc++/20806. #define _GLIBCXX_HAVE_DOS_BASED_FILESYSTEM 1 -// See libstdc++/37522. -#define _GLIBCXX_HAVE_BROKEN_VSWPRINTF 1 - // See libstdc++/43738 // On native windows targets there is no ioctl function. And the existing // ioctlsocket function doesn't work for normal file-descriptors. signature.asc Description: OpenPGP digital signature
Re: [Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from (was Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon)
Applied. Thanks, Paolo.
Re: [Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from (was Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon)
On 31 October 2012 11:23, JonY wrote: On 10/31/2012 19:12, Jonathan Wakely wrote: It looks like the workaround is in mingw not in GCC, so is it a problem that it won't be possible to use GCC 4.8 with existing mingw versions, or are users required to use a brand new mingw to use a new GCC? Should that be documented in http://gcc.gnu.org/gcc-4.8/changes.html ? They are required to use the latest mingw-w64, the problem was that the vfswprintf that libstdc++ expects isn't the same as the one MS provides, so I've wrote a redirector to use the vsnwprintf, more precisely, the mingw C99 compliant __mingw_vsnwprintf. std::to_wstring and std::to_string work according to some simple tests. Excellent, the testsuite should automatically start running the relevant tests and we should be able to close http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 I guess the current comment about require mingw-w64 trunk at least r5437 is OK for the changes page. It should probably note that this change is mingw-w64 specific, with w64 as the vendor key. i.e. *-w64-mingw* ? Or is *-w64-mingw32 more accurate? (I don't really know how the mingw target triplets work, sorry!) I'll put something in the changes page later. Thanks for fixing this.
Re: [Patch] Remove _GLIBCXX_HAVE_BROKEN_VSWPRINTF from (was Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon)
On 10/31/2012 20:01, Jonathan Wakely wrote: On 31 October 2012 11:23, JonY wrote: On 10/31/2012 19:12, Jonathan Wakely wrote: It looks like the workaround is in mingw not in GCC, so is it a problem that it won't be possible to use GCC 4.8 with existing mingw versions, or are users required to use a brand new mingw to use a new GCC? Should that be documented in http://gcc.gnu.org/gcc-4.8/changes.html ? They are required to use the latest mingw-w64, the problem was that the vfswprintf that libstdc++ expects isn't the same as the one MS provides, so I've wrote a redirector to use the vsnwprintf, more precisely, the mingw C99 compliant __mingw_vsnwprintf. std::to_wstring and std::to_string work according to some simple tests. Excellent, the testsuite should automatically start running the relevant tests and we should be able to close http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 Yes, the correct way would be to check if the prototype given matches the ISO version. MS version has 1 less argument. The workaround is only active when C++11 is used though to maintain compatibility to older code. The actual guard in the mingw-w64: #if defined(__cplusplus) (__cplusplus = 201103L) !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF) ...Redirect to ISO C99 compliant adapter with 4 args... #else ...Use MS Version with 3 args... #endif So the tests and checks would just need to use -std=c++11 or gnu++11. I guess the current comment about require mingw-w64 trunk at least r5437 is OK for the changes page. It should probably note that this change is mingw-w64 specific, with w64 as the vendor key. i.e. *-w64-mingw* ? Or is *-w64-mingw32 more accurate? (I don't really know how the mingw target triplets work, sorry!) In practice, *-w64-mingw32 is used more commonly when specifying triplet, though for flexibility, checking should use *-w64-mingw*. I'll put something in the changes page later. Thanks for fixing this. Thanks to Paolo for pushing it in too. signature.asc Description: OpenPGP digital signature
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Richi, Let me explain to you what a broken api is. I have spent the last week screwing around with tree-vpn and as of last night i finally got it to work. In tree-vpn, it is clear that double-int is the precise definition of a broken api. The tree-vpn uses an infinite-precision view of arithmetic. However, that infinite precision is implemented on top of a finite, CARVED IN STONE, base that is and will always be without a patch like this, 128 bits on an x86-64.However, as was pointed out by earlier, tree-vrp needs 2 * the size of a type + 1 bit to work correctly.Until yesterday i did not fully understand the significance of that 1 bit. what this means is that tree-vrp does not work on an x86-64 with _int128 variables. There are no checks in tree-vrp to back off when it sees something too large, tree-vrp simply gets the wrong answer. To me, this is a broken api and is GCC at its very worst. The patches that required this SHOULD HAVE NEVER GONE INTO GCC. What you have with my patches is someone who is willing to fix a large and complex problem that should have been fixed years ago. I understand that you do not like several aspects of the wide-int api and i am willing to make some of those improvements. However, what i am worried about is that you are in some ways really attached to the style of programmed where everything is dependent on the size of a HWI.I will continue to push back on those comments but have been working the rest in as i have been going along. To answer your other question, it will be a significant problem if i cannot get these patches in. They are very prone to patch rot and my customer wants a product without many patches to the base code. Also, i fear that your real reason that you want to wait is because you really do not like the fact these patches get rid of double in and that style of programming and putting off that day serves no one well. kenny On 10/31/2012 05:59 AM, Richard Sandiford wrote: Richard Bienerrichard.guent...@gmail.com writes: On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: jakub, i am hoping to get the rest of my wide integer conversion posted by nov 5. I am under some adverse conditions here: hurricane sandy hit her pretty badly. my house is hooked up to a small generator, and no one has any power for miles around. So far richi has promised to review them. he has sent some comments, but so far no reviews.Some time after i get the first round of them posted, i will do a second round that incorporates everyones comments. But i would like a little slack here if possible.While this work is a show stopper for my private port, the patches address serious problems for many of the public ports, especially ones that have very flexible vector units.I believe that there are significant set of latent problems currently with the existing ports that use ti mode that these patches will fix. However, i will do everything in my power to get the first round of the patches posted by nov 5 deadline. I suppose you are not going to merge your private port for 4.8 and thus the wide-int changes are not a show-stopper for you. That said, I considered the main conversion to be appropriate to be defered for the next stage1. There is no advantage in disrupting the tree more at this stage. I would like the wide_int class and rtl stuff to go in 4.8 though. IMO it's a significant improvement in its own right, and Kenny submitted it well before the deadline. Richard
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Wed, Oct 31, 2012 at 09:44:50AM -0400, Kenneth Zadeck wrote: The tree-vpn uses an infinite-precision view of arithmetic. However, that infinite precision is implemented on top of a finite, CARVED IN STONE, base that is and will always be without a patch like this, 128 bits on an x86-64.However, as was pointed out by earlier, tree-vrp needs 2 * the size of a type + 1 bit to work correctly. Until yesterday i did not fully understand the significance of that 1 bit. what this means is that tree-vrp does not work on an x86-64 with _int128 variables. If you see a VRP bug, please file a PR with a testcase, or point to existing PR. I agree with richi that it would be better to add a clean wide_int implementation for 4.9, rather than rushing something in, introducing lots of bugs, just for a port that hasn't been submitted, nor I understand why int128_t integer types are so crucial to your port, the vector support doesn't generally need very large integers, even if your vector unit is 256-bit, 512-bit or larger. Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
jakub my port has 256 bit integers. They are done by strapping together all of the elements of a vector unit. if one looks at where intel is going, they are doing exactly the same thing.The difference is that they like to add the operations one at a time rather than just do a clean implementation like we did. Soon they will get there, it is just a matter of time. i understand the tree-vrp code well enough to say that this operation does not work if you have timode, but i do not know how to translate that back into c to generate a test case.My patch to tree-vrp is adaptable in that it looks at the types in the program and adjusts its definition of infinite precision based on the code that it sees. I can point people to that code in tree vrp and am happy to do that, but that is not my priority now. also, richi pointed out that there are places in the tree level constant propagators that require infinite precision so he is really the person who both should know about this and generate proper tests. kenny On 10/31/2012 09:55 AM, Jakub Jelinek wrote: On Wed, Oct 31, 2012 at 09:44:50AM -0400, Kenneth Zadeck wrote: The tree-vpn uses an infinite-precision view of arithmetic. However, that infinite precision is implemented on top of a finite, CARVED IN STONE, base that is and will always be without a patch like this, 128 bits on an x86-64.However, as was pointed out by earlier, tree-vrp needs 2 * the size of a type + 1 bit to work correctly. Until yesterday i did not fully understand the significance of that 1 bit. what this means is that tree-vrp does not work on an x86-64 with _int128 variables. If you see a VRP bug, please file a PR with a testcase, or point to existing PR. I agree with richi that it would be better to add a clean wide_int implementation for 4.9, rather than rushing something in, introducing lots of bugs, just for a port that hasn't been submitted, nor I understand why int128_t integer types are so crucial to your port, the vector support doesn't generally need very large integers, even if your vector unit is 256-bit, 512-bit or larger. Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Wed, Oct 31, 2012 at 10:04:58AM -0400, Kenneth Zadeck wrote: if one looks at where intel is going, they are doing exactly the same thing.The difference is that they like to add the operations one at a time rather than just do a clean implementation like we did. Soon they will get there, it is just a matter of time. All I see on Intel is whole vector register shifts (and like on many other ports and/or/xor/andn could be considered whole register too). And, even if your port has 256-bit integer arithmetics, there is no mangling for __int256_t or similar, so I don't see how you can offer such data type as supported in the 4.8 timeframe. Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
I was not planning to do that mangling for 4.8.My primary justification for getting it in publicly now is that there are a large number of places where the current compiler (both at the tree and rtl levels) do not do optimization of the value is larger than a single hwi.My code generalizes all of these places so that they do the transformations independent of the size of the hwi. (in some cases at the rtl level, the transformations were only done on 32 bit or smaller types, but i have seen nothing like that at the tree level.) This provides benefits for cross compilers and for ports that support timode now. The fact that i have chosen to do it in such a way that we will never have this problem again is the part of the patch that richi seems to object to. We have patches that do the mangling for 256 for the front ends but we figured that we would post those for comments. These are likely to be controversial because the require extensions to the syntax to accept large constants. But there is no reason why the patches that fix the existing problems in a general way should not be considered for this release. Kenny On 10/31/2012 10:27 AM, Jakub Jelinek wrote: On Wed, Oct 31, 2012 at 10:04:58AM -0400, Kenneth Zadeck wrote: if one looks at where intel is going, they are doing exactly the same thing.The difference is that they like to add the operations one at a time rather than just do a clean implementation like we did. Soon they will get there, it is just a matter of time. All I see on Intel is whole vector register shifts (and like on many other ports and/or/xor/andn could be considered whole register too). And, even if your port has 256-bit integer arithmetics, there is no mangling for __int256_t or similar, so I don't see how you can offer such data type as supported in the 4.8 timeframe. Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 10/31/2012 09:49 AM, Richard Biener wrote: On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck zad...@naturalbridge.com wrote: jakub, i am hoping to get the rest of my wide integer conversion posted by nov 5. I am under some adverse conditions here: hurricane sandy hit her pretty badly. my house is hooked up to a small generator, and no one has any power for miles around. So far richi has promised to review them. he has sent some comments, but so far no reviews.Some time after i get the first round of them posted, i will do a second round that incorporates everyones comments. But i would like a little slack here if possible.While this work is a show stopper for my private port, the patches address serious problems for many of the public ports, especially ones that have very flexible vector units.I believe that there are significant set of latent problems currently with the existing ports that use ti mode that these patches will fix. However, i will do everything in my power to get the first round of the patches posted by nov 5 deadline. I suppose you are not going to merge your private port for 4.8 and thus the wide-int changes are not a show-stopper for you. That said, I considered the main conversion to be appropriate to be defered for the next stage1. There is no advantage in disrupting the tree more at this stage. We are still in Stage 1. If it were later in the release cycle this argument would have some merit, but under the rules this sort of thing is allowed at any point in Stage 1. If we aren't going to allow something like this because it's too late we should have closed Stage 1 earlier. Andrew.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Jakub,
it is hard from all of the threads to actually distill what the real
issues are here. So let me start from a clean slate and state them simply.
Richi has three primary objections:
1) that we can do all of this with a templated version of double-int.
2) that we should not be passing in a precision and bitsize into the
interface.
3) that the interface is too large.
I have attached a fragment of my patch #5 to illustrate the main thrust
of my patches and to illustrate the usefulness to gcc right now.
In the current trunk, we have code that does simplification when the
mode fits in an HWI and we have code that does the simplification if the
mode fits in two HWIs. if the mode does not fit in two hwi's the code
does not do the simplification.
Thus here and in a large number of other places we have two copies of
the code.Richi wants there to be multiple template instantiations of
double-int.This means that we are now going to have to have 3 copies
of this code to support oi mode on a 64 bit host and 4 copies on a 32
bit host.
Further note that there are not as many cases for the 2*hwi in the code
as their are for the hwi case and in general this is true through out
the compiler. (CLRSB is missing from the 2hwi case in the patch) We
really did not write twice the code when we stated supporting 2 hwi, we
added about 1.5 times the code (simplify-rtx is better than most of the
rest of the compiler). I am using the rtl level as an example here
because i have posted all of those patches, but the tree level is no
better.
I do not want to write this code a third time and certainly not a fourth
time. Just fixing all of this is quite useful now: it fills in a lot
of gaps in our transformations and it removes many edge case crashes
because ti mode really is lightly tested. However, this patch becomes
crucial as the world gets larger.
Richi's second point is that we should be doing everything at infinite
precision and not passing in an explicit bitsize and precision. That
works ok (sans the issues i raised with it in tree-vpn earlier) when the
largest precision on the machine fits in a couple of hwis.However,
for targets that have large integers or cross compilers, this becomes
expensive.The idea behind my set of patches is that for the
transformations that can work this way, we do the math in the precision
of the type or mode. In general this means that almost all of the math
will be done quickly, even on targets that support really big
integers. For passes like tree-vrp, the math will be done at some
multiple of the largest type seen in the actual program.The amount
of the multiple is a function of the optimization, not the target or the
host. Currently (on my home computer) the wide-int interface allows the
optimization to go 4x the largest mode on the target.
I can get rid of this bound at the expense of doing an alloca rather
than stack allocating a fixed sized structure.However, given the
extremely heavy use of this interface, that does not seem like the best
of tradeoffs.
The truth is that the vast majority of the compiler actually wants to
see the math done the way that it is going to be done on the machine.
Tree-vrp and the gimple constant prop do not. But i have made
accommodations to handle both needs.I believe that the reason that
double-int was never used at the rtl level is that it does not actually
do the math in a way that is useful to the target.
Richi's third objection is that the interface is too large. I
disagree. It was designed based on the actual usage of the
interface. When i found places where i was writing the same code over
and over again, i put it in a function as part of the interface. I
later went back and optimized many of these because this is a very
heavily used interface. Richi has many other objections, but i have
agreed to fix almost all of them, so i am not going to address them here.
It really will be a huge burden to have to carry these patched until the
next revision. We are currently in stage 1 and i believe that the minor
issues that richi raises can be easily addressed.
kenny
@@ -1373,302 +1411,87 @@ simplify_const_unary_operation (enum rtx_code code, enum machine_mode mode,
return CONST_DOUBLE_FROM_REAL_VALUE (d, mode);
}
- if (CONST_INT_P (op)
- width = HOST_BITS_PER_WIDE_INT width 0)
+ if (CONST_SCALAR_INT_P (op) width 0)
{
- HOST_WIDE_INT arg0 = INTVAL (op);
- HOST_WIDE_INT val;
+ wide_int result;
+ enum machine_mode imode = op_mode == VOIDmode ? mode : op_mode;
+ wide_int op0 = wide_int::from_rtx (op, imode);
+
+#if TARGET_SUPPORTS_WIDE_INT == 0
+ /* This assert keeps the simplification from producing a result
+ that cannot be represented in a CONST_DOUBLE but a lot of
+ upstream callers expect that this function never fails to
+ simplify something and so you if you added this
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Wed, 31 Oct 2012, Kenneth Zadeck wrote: Richi, Let me explain to you what a broken api is. I have spent the last week screwing around with tree-vpn and as of last night i finally got it to work. In tree-vpn, it is clear that double-int is the precise definition of a broken api. The tree-vpn uses an infinite-precision view of arithmetic. However, that infinite precision is implemented on top of a finite, CARVED IN STONE, base that is and will always be without a patch like this, 128 bits on an x86-64. However, as was pointed out by earlier, tree-vrp needs 2 * the size of a type + 1 bit to work correctly.Until yesterday i did not fully understand the significance of that 1 bit. what this means is that tree-vrp does not work on an x86-64 with _int128 variables. I am a bit surprised by that. AFAIK, the wrapping multiplication case is the only place that uses quad-sized arithmetic, so that must be what you are talking about. But when I wrote that code, I was well aware of the need for that extra bit and worked around it using signed / unsigned as an extra bit of information. So if you found a bug there, I'd like to know (although it becomes moot once the code is replaced with wide_int). Note that my original patch for VRP used the GMP library for computations (it was rejected as likely too slow), so I think simplifying the thing with a multi-precision type is great. And if as you explained you have one (large) fixed size used for all temporaries on the stack but never used for malloc'ed objects, that sounds good too. Good luck with the useful wide_int work, -- Marc Glisse
RE: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Hi Jakub, We are working on the following. 1. bdver3 enablement. Review completed. Changes to be incorporated and checked-in. http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01131.html 2. btver2 basic enablement is done (http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01018.html)/ Scheduler descriptions are being updated. This is architecture specific and we consider it not to be a stage-1 material. Regards Ganesh -Original Message- From: Jakub Jelinek [mailto:ja...@redhat.com] Sent: Monday, October 29, 2012 11:27 PM To: g...@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org Subject: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Quality Data Priority # Change from Last Report --- --- P1 23 + 23 P2 77 + 8 P3 85 + 84 --- --- Total 185 +115 Previous Report === http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html The next report will be sent by me again, announcing end of stage 1.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Oct 29, 2012 at 02:07:55PM -0400, David Miller wrote: I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. I'd like to get the Sparc cbcond stuff in (3 revisions posted) which is waiting for Eric B. to do some Solaris specific work. That has been posted in stage 1, so it is certainly ok to commit it even during early stage 3. And, on a case by case basis exceptions are always possible. This hasn't changed in the last few years. By the reviewed shortly after the freeze I just want to say that e.g. having large intrusive patches posted now, but reviewed late December is already too late. As for postponing end of stage 1 by a few weeks because of the storm, I'm afraid if we want to keep roughly timely releases we don't have that luxury. If you look at http://gcc.gnu.org/develop.html, ending stage 1 around end of October happened already for 4.6 and 4.7, for 4.5 if was a month earlier and for 4.4 even two months earlier. The 4.7 bugfixing went IMHO smothly, but we certainly have to expect lots of bugfixing. I'd also like to enable LRA for at least 32-bit sparc, even if I can't find the time to work on auditing 64-bit completely. I agree with Eric that it is better to enable it for the whole target together, rather than based on some options. Enabling LRA in early stage 3 for some targets should be ok, if it doesn't require too large and intrusive changes to the generic code that could destabilize other targets. Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Oct 29, 2012 at 1:56 PM, Jakub Jelinek ja...@redhat.com wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. I will be committing the VEC overhaul soon. With any luck this week, but PCH and gengtype are giving me a lot of grief. Diego.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
jakub, i am hoping to get the rest of my wide integer conversion posted by nov 5. I am under some adverse conditions here: hurricane sandy hit her pretty badly. my house is hooked up to a small generator, and no one has any power for miles around. So far richi has promised to review them. he has sent some comments, but so far no reviews.Some time after i get the first round of them posted, i will do a second round that incorporates everyones comments. But i would like a little slack here if possible.While this work is a show stopper for my private port, the patches address serious problems for many of the public ports, especially ones that have very flexible vector units.I believe that there are significant set of latent problems currently with the existing ports that use ti mode that these patches will fix. However, i will do everything in my power to get the first round of the patches posted by nov 5 deadline. kenny On 10/29/2012 01:56 PM, Jakub Jelinek wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Quality Data Priority # Change from Last Report --- --- P1 23 + 23 P2 77 + 8 P3 85 + 84 --- --- Total 185 +115 Previous Report === http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html The next report will be sent by me again, announcing end of stage 1.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 10/30/12, Diego Novillo dnovi...@google.com wrote: On Mon, Oct 29, 2012 at 1:56 PM, Jakub Jelinek ja...@redhat.com wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. I will be committing the VEC overhaul soon. With any luck this week, but PCH and gengtype are giving me a lot of grief. I have three remaining bitmap patches and the recently approved is_a/symtab/cgraph patch. However, Alexandre Oliva aol...@redhat.com has a patch for bootstrap failure that is biting me. I can either incorporate it into my patches or wait for his patch and then submit. Comments? -- Lawrence Crowl
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Hi Jakub, My function multiversioning patch is being reviewed and I hope to get this in by Nov. 5. Thanks, -Sri. On Mon, Oct 29, 2012 at 10:56 AM, Jakub Jelinek ja...@redhat.com wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Quality Data Priority # Change from Last Report --- --- P1 23 + 23 P2 77 + 8 P3 85 + 84 --- --- Total 185 +115 Previous Report === http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html The next report will be sent by me again, announcing end of stage 1.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Hi Jakub, My -fopt-info pass filtering patch (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02704.html) is being reviewed and I hope to get this in by Nov. 5 for inclusion in gcc 4.8.0. Thanks, Sharad On Mon, Oct 29, 2012 at 10:56 AM, Jakub Jelinek ja...@redhat.com wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Quality Data Priority # Change from Last Report --- --- P1 23 + 23 P2 77 + 8 P3 85 + 84 --- --- Total 185 +115 Previous Report === http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html The next report will be sent by me again, announcing end of stage 1.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
From: Jakub Jelinek ja...@redhat.com Date: Mon, 29 Oct 2012 18:56:42 +0100 I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. I'd like to get the Sparc cbcond stuff in (3 revisions posted) which is waiting for Eric B. to do some Solaris specific work. I'd also like to enable LRA for at least 32-bit sparc, even if I can't find the time to work on auditing 64-bit completely.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
I'd like to get the Sparc cbcond stuff in (3 revisions posted) which is waiting for Eric B. to do some Solaris specific work. I'd also like to enable LRA for at least 32-bit sparc, even if I can't find the time to work on auditing 64-bit completely. End of stage #1 isn't a hard limit for architecture-specific patches, so we need not make a decision about LRA immediately. I don't think we want to half enable it though, so it's all or nothing. -- Eric Botcazou
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
From: Eric Botcazou ebotca...@adacore.com Date: Mon, 29 Oct 2012 20:25:15 +0100 I'd like to get the Sparc cbcond stuff in (3 revisions posted) which is waiting for Eric B. to do some Solaris specific work. I'd also like to enable LRA for at least 32-bit sparc, even if I can't find the time to work on auditing 64-bit completely. End of stage #1 isn't a hard limit for architecture-specific patches, so we need not make a decision about LRA immediately. I don't think we want to half enable it though, so it's all or nothing. Upon further consideration, agreed. I'll only turn this on if I can get the whole backend working. FWIW, I think we should consider delaying stage1 for another reason. A large number of North American developers are about to be hit by a major natural disaster, and may be without power for weeks.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
måndag 29 oktober 2012 18.56.42 skrev Jakub Jelinek: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. I want to get the new configure --enable-espf options included. The patches have been posted some time ago. Gentoo Hardened Project Magnus Granberg
