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: gcc@gcc.gnu.org > Cc: gcc-patc...@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 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 writes: > On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck > 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 wrote: > Richard Biener writes: >> On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck >> 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 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.
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 Biener writes: On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck 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
g++.dg/tree-ssa/pr45453.C time out
Hi, whoever a few days ago or so broke this test, can please either fix the testcase, the compiler or just xfail for now the testcase itself, to avoid everybody the waste of time? If you want me to do go ahead with option 3 above, just let me know! Thanks! Paolo.
Re: g++.dg/tree-ssa/pr45453.C time out
On Wed, Oct 31, 2012 at 3:17 PM, Paolo Carlini wrote: > Hi, > > whoever a few days ago or so broke this test, can please either fix the > testcase, the compiler or just xfail for now the testcase itself, to avoid > everybody the waste of time? > > If you want me to do go ahead with option 3 above, just let me know! It was honza - we endlessly recurse in estimate_calls_size_and_time. Honza, please make fixing this a priority. Thanks, Richard.
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: g++.dg/tree-ssa/pr45453.C time out
> On Wed, Oct 31, 2012 at 3:17 PM, Paolo Carlini > wrote: > > Hi, > > > > whoever a few days ago or so broke this test, can please either fix the > > testcase, the compiler or just xfail for now the testcase itself, to avoid > > everybody the waste of time? > > > > If you want me to do go ahead with option 3 above, just let me know! > > It was honza - we endlessly recurse in estimate_calls_size_and_time. > > Honza, please make fixing this a priority. I am looing into it now. Did not noticed that - at -O3 it hits the ipa-cp issue I hope Martin will fix. The problem here is not infinite recursion, we keep inlning the foo into itself since indirect inlining somehow misses the limits on recursion depth and the function is empty and thus inlining has no cost. Honza > > Thanks, > Richard.
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: g++.dg/tree-ssa/pr45453.C time out
> > On Wed, Oct 31, 2012 at 3:17 PM, Paolo Carlini
> > wrote:
> > > Hi,
> > >
> > > whoever a few days ago or so broke this test, can please either fix the
> > > testcase, the compiler or just xfail for now the testcase itself, to avoid
> > > everybody the waste of time?
> > >
> > > If you want me to do go ahead with option 3 above, just let me know!
> >
> > It was honza - we endlessly recurse in estimate_calls_size_and_time.
> >
> > Honza, please make fixing this a priority.
>
> I am looing into it now. Did not noticed that - at -O3 it hits the ipa-cp
> issue
> I hope Martin will fix.
>
> The problem here is not infinite recursion, we keep inlning the foo into
> itself
> since indirect inlining somehow misses the limits on recursion depth and the
> function is empty and thus inlining has no cost.
The problem is that with new costs and new code for inlining functions called
once
we end up inlining empty virutal function to itself hoping to kill it.
I am testing the following that makes us to give up in such a werid case.
Index: ipa-inline.c
===
--- ipa-inline.c(revision 193035)
+++ ipa-inline.c(working copy)
@@ -1767,29 +1878,41 @@ ipa_inline (void)
FOR_EACH_DEFINED_FUNCTION (node)
{
if (want_inline_function_to_all_callers_p (node, cold))
- while (node->callers && !node->global.inlined_to)
- {
- struct cgraph_node *caller = node->callers->caller;
+ {
+ int num_calls = 0;
+ struct cgraph_edge *e;
+ for (e = node->callers; e; e = e->next_caller)
+ num_calls++;
+ while (node->callers && !node->global.inlined_to)
+ {
+ struct cgraph_node *caller = node->callers->caller;
+
+ if (dump_file)
+ {
+ fprintf (dump_file,
+ "\nInlining %s size %i.\n",
+ cgraph_node_name (node),
+ inline_summary (node)->size);
+ fprintf (dump_file,
+ " Called once from %s %i insns.\n",
+ cgraph_node_name (node->callers->caller),
+ inline_summary
(node->callers->caller)->size);
+ }
- if (dump_file)
- {
+ inline_call (node->callers, true, NULL, NULL, true);
+ if (dump_file)
fprintf (dump_file,
-"\nInlining %s size %i.\n",
-cgraph_node_name (node),
-inline_summary (node)->size);
- fprintf (dump_file,
-" Called once from %s %i insns.\n",
-cgraph_node_name (node->callers->caller),
-inline_summary (node->callers->caller)->size);
- }
-
- inline_call (node->callers, true, NULL, NULL, true);
- if (dump_file)
- fprintf (dump_file,
- " Inlined into %s which now has %i size\n",
- cgraph_node_name (caller),
- inline_summary (caller)->size);
- }
+" Inlined into %s which now has %i size\n",
+cgraph_node_name (caller),
+inline_summary (caller)->size);
+ if (!num_calls--)
+ {
+ if (dump_file)
+ fprintf (dump_file, "New calls found; giving
up.\n");
+ break;
+ }
+ }
+ }
}
}
}
[ANN] gcc-lua: Lua plugin for the GNU Compiler Collection
Hi, It is my pleasure to announce gcc-lua: gcc‑lua extends the GNU Compiler Collection with the ability to run Lua scripts. The plugin provides an interface to register callback functions for plugin events, and inspect the abstract syntax tree of a translation unit. The plugin is useful for static C code analysis. gcc‑lua supports GCC 4.6 or 4.7, and, Lua 5.1 or 5.2, or LuaJIT. http://colberg.org/gcc-lua/ Regards, Peter
Bad and/or stupid code for DImode compares with gcc 4.6.1
I'm looking at code generated for a new port of gcc using 4.6.1 and failing execute/950607-2.c with -O0 only The target chip has only 32 bit instructions, so it's using do_jump_by_parts__rtx() to expand the compare. I've set up my .md to use the CCmode. I see one case that seems really stupid, and one that's just wrong. I'm thinking that either I have something really flawed with my port's handing of DImode or that there was a bug in 4.6.1.The port is only failing about 2100 dejagnu tests (passing 64000+) and a good chunk of the failures are due to the ridiculously small data-memory size of the chip. For long long int x; if ( x < 0 ) return 0 else return 2; I see code that compares MSBs and branches on < (less than) as expected. But then it goes and checks the MSBs for != , and finally it checks the LSBS and emits a conditional branch to the ELSE, followed by an unconditional branch to the ELSE, so that I end up with code that looks like mov $r1,x mov $r2,x+4 cmpi $r2,0 jlt .L5 cmpi $r2,0 <=== totally redundant for "x < 0" comparisons jne .L2 cmpi $r1,0 jmp .L4 .L5 : movi $r1, 0 jump .L4 .L2 : movi $r1, 2 .L4: ret This is a simplification of 950607-2.c, which fails at -O0, but passes at higher optimization levels (go figure...)
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 > 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 a
Re: Bad and/or stupid code for DImode compares with gcc 4.6.1
So, I found the patch to do_jump_by_parts_greater_rtx() by Eric Botcazou that should address the stupid code and the redundant branch. Should have done a broader search before I wasted email bandwidth... On Oct 31, 2012, at 1:51 PM, Alan Lehotsky wrote: > I'm looking at code generated for a new port of gcc using 4.6.1 and failing > execute/950607-2.c with -O0 only > > The target chip has only 32 bit instructions, so it's using > do_jump_by_parts__rtx() to expand the compare. > I've set up my .md to use the CCmode. > > I see one case that seems really stupid, and one that's just wrong. I'm > thinking that either I have something really flawed with my port's handing of > DImode or that there was a bug in 4.6.1.The port is only failing about > 2100 dejagnu tests (passing 64000+) and a good chunk of the failures are due > to the ridiculously small data-memory size of the chip. > > For > > long long int x; > >if ( x < 0 ) return 0 else return 2; > > I see code that compares MSBs and branches on < (less than) as expected. But > then it goes and checks the MSBs for != , and finally it checks the LSBS and > emits a conditional branch to the ELSE, followed by an unconditional branch > to the ELSE, so that I end up with code that looks like > > mov $r1,x > mov $r2,x+4 >cmpi $r2,0 >jlt .L5 >cmpi $r2,0 <=== totally redundant for "x < 0" comparisons >jne .L2 >cmpi $r1,0 >jmp .L4 > > .L5 : movi $r1, 0 > jump .L4 > > .L2 : movi $r1, 2 > > .L4: > ret > > > This is a simplification of 950607-2.c, which fails at -O0, but passes at > higher optimization levels (go figure...) >
Re: Bad and/or stupid code for DImode compares with gcc 4.6.1
> I see one case that seems really stupid, and one that's just wrong. I'm > thinking that either I have something really flawed with my port's handing > of DImode or that there was a bug in 4.6.1.The port is only failing > about 2100 dejagnu tests (passing 64000+) and a good chunk of the failures > are due to the ridiculously small data-memory size of the chip. Please do not use "bad code", it's ambiguous, always use "wrong code" instead. > For > > long long int x; > > if ( x < 0 ) return 0 else return 2; > > I see code that compares MSBs and branches on < (less than) as expected. > But then it goes and checks the MSBs for != , and finally it checks the > LSBS and emits a conditional branch to the ELSE, followed by an > unconditional branch to the ELSE, so that I end up with code that looks > like > > mov $r1,x > mov $r2,x+4 > cmpi $r2,0 > jlt .L5 > cmpi $r2,0 <=== totally redundant for "x < 0" comparisons > jne .L2 > cmpi $r1,0 > jmp .L4 > > .L5 : movi $r1, 0 > jump .L4 > > .L2 : movi $r1, 2 > > .L4: > ret While poor code is expected at -O0, wrong code isn't of course. Could you post a compilable testcase instead of an excerpt and the contents of the .expand dump file (compile with -fdump-rtl-expand to get it)? -- Eric Botcazou
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: Dealing with C++98/11 ABI incompatibilities
On 07/03/2012 03:18 PM, Jason Merrill wrote:
2) Object layout changes to std::list and std::basic_string. For these
types, there is no way to both retain backward compatibility with older
C++98 code and conform to the C++11 standard. The best we can hope for
is to allow old code to coexist with new code so long as they don't try
to touch the same string/list objects.
As above, one solution to this would be to change the linkage name of
the new versions so that they don't clash with the old versions. But
that isn't enough in this case, as it wouldn't affect the linkage name
of a class like
struct Wrap { std::string s; };
so we would need some way to cause the name decoration to propagate to
other containing/derived classes.
I raised this issue on the ABI list, and someone pointed out to me that
incomplete classes make quiet propagation impossible; any full
coexistence solution will require changes to affected user types. There
seem to be two options:
1) No propagation, add a warning to suggest that users decorate their
types appropriately.
2) Propagate to class definitions, give an error if there was an earlier
forward declaration without the appropriate tag.
I lean toward #1; people who rebuild everything regularly won't be
affected by it, and people who need coexistence can use the warning flag
to help them adjust.
Jason
Re: g++.dg/tree-ssa/pr45453.C time out
The problem is that with new costs and new code for inlining functions called once we end up inlining empty virutal function to itself hoping to kill it. I am testing the following that makes us to give up in such a werid case. Thanks! Paolo.
