Value numbering and volatility
Hi,
We're experiencing a memory explosion during PRE on several ACATS tests with
mainline (+1 local patch, but it's very likely the same issue as PR 27937).
Excerpt from .067t.pre:
Created value VH.26 for (struct cd5012i__genproc__cell *volatile & {ref-all})
VH.25
Created value VH.33 for *VH.26 vuses: (fcndecl__var0_49,HEAP.8_51,SMT.10_52)
Created value VH.34 for *VH.26 vuses: (fcndecl__var0_49,HEAP.8_51,SMT.10_52)
Created value VH.47 for *VH.26 vuses: (fcndecl__var0_49,HEAP.8_51,SMT.10_52)
Created value VH.49 for *VH.26 vuses: (fcndecl__var0_49,HEAP.8_51,SMT.10_52)
[...]
and so on ad nauseam. The problem boils down to operand_equal_p returning
false on
operand_equal_p (arg0=0x93dc744, arg1=0x94d4724, flags=2)
at /home/eric/gnat/gnat6/src/gcc/fold-const.c:2491
2491 if (TREE_CODE (arg0) == ERROR_MARK || TREE_CODE (arg1) ==
ERROR_MARK)
(gdb) p debug_tree(arg0)
unit size
align 32 symtab 0 alias set 5 fields
Ada size
pointer_to_this chain >
sizes-gimplified volatile public unsigned SI
size
unit size
user align 32 symtab 0 alias set -1 reference_to_this >
side-effects volatile
arg 0
sizes-gimplified static unsigned SI size unit size
align 32 symtab 0 alias set -1>
>
cd5012i.adb:27>
$5 = void
(gdb) p debug_tree(arg1)
unit size
align 32 symtab 0 alias set 5 fields
Ada size
pointer_to_this chain >
sizes-gimplified volatile public unsigned SI
size
unit size
user align 32 symtab 0 alias set -1 reference_to_this >
side-effects volatile
arg 0
sizes-gimplified static unsigned SI size unit size
align 32 symtab 0 alias set -1>
>
cd5012i.adb:27>
$6 = void
i.e. 2 dereferences of the same volatile VALUE_HANDLE because of:
case tcc_reference:
/* If either of the pointer (or reference) expressions we are
dereferencing contain a side effect, these cannot be equal. */
if (TREE_SIDE_EFFECTS (arg0)
|| TREE_SIDE_EFFECTS (arg1))
return 0;
It seems to me that the volatility should be accounted for in the VALUE_HANDLE
itself only, not in (de)references to it.
Thoughts?
--
Eric Botcazou
Re: Value numbering and volatility
On 6/21/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
Hi,
We're experiencing a memory explosion during PRE on several ACATS tests with
mainline (+1 local patch, but it's very likely the same issue as PR 27937).
Excerpt from .067t.pre:
Created value VH.26 for (struct cd5012i__genproc__cell *volatile & {ref-all})
VH.25
Created value VH.33 for *VH.26 vuses: (fcndecl__var0_49,HEAP.8_51,SMT.10_52)
Created value VH.34 for *VH.26 vuses: (fcndecl__var0_49,HEAP.8_51,SMT.10_52)
Created value VH.47 for *VH.26 vuses: (fcndecl__var0_49,HEAP.8_51,SMT.10_52)
Created value VH.49 for *VH.26 vuses: (fcndecl__var0_49,HEAP.8_51,SMT.10_52)
[...]
and so on ad nauseam. The problem boils down to operand_equal_p returning
false on
operand_equal_p (arg0=0x93dc744, arg1=0x94d4724, flags=2)
at /home/eric/gnat/gnat6/src/gcc/fold-const.c:2491
2491 if (TREE_CODE (arg0) == ERROR_MARK || TREE_CODE (arg1) ==
ERROR_MARK)
(gdb) p debug_tree(arg0)
unit size
align 32 symtab 0 alias set 5 fields
Ada size
pointer_to_this chain >
sizes-gimplified volatile public unsigned SI
size
unit size
user align 32 symtab 0 alias set -1 reference_to_this >
side-effects volatile
arg 0
sizes-gimplified static unsigned SI size unit size
align 32 symtab 0 alias set -1>
>
cd5012i.adb:27>
$5 = void
(gdb) p debug_tree(arg1)
unit size
align 32 symtab 0 alias set 5 fields
Ada size
pointer_to_this chain >
sizes-gimplified volatile public unsigned SI
size
unit size
user align 32 symtab 0 alias set -1 reference_to_this >
side-effects volatile
arg 0
sizes-gimplified static unsigned SI size unit size
align 32 symtab 0 alias set -1>
>
cd5012i.adb:27>
$6 = void
i.e. 2 dereferences of the same volatile VALUE_HANDLE because of:
case tcc_reference:
/* If either of the pointer (or reference) expressions we are
dereferencing contain a side effect, these cannot be equal. */
if (TREE_SIDE_EFFECTS (arg0)
|| TREE_SIDE_EFFECTS (arg1))
return 0;
It seems to me that the volatility should be accounted for in the VALUE_HANDLE
itself only, not in (de)references to it.
Thoughts?
What do you mean by "in the VALUE_HANDLE itself"? I think we should not bother
value-numbering volatile mem-accesses at all.
Richard.
Re: Value numbering and volatility
On Jun 21, 2006, at 7:05 AM, Eric Botcazou wrote: Hi, We're experiencing a memory explosion during PRE on several ACATS tests with mainline (+1 local patch, but it's very likely the same issue as PR 27937). The VN should not have been created and stmt_ann (stmt)- >has_volatile_ops should have been true. -- Pinski
Re: Value numbering and volatility
> What do you mean by "in the VALUE_HANDLE itself"? Returning a different VALUE_HANDLE for each instance of a volatile expression. > I think we should not bother value-numbering volatile mem-accesses at all. I guess that would be even better. :-) Thanks for the quick feedback. -- Eric Botcazou
Re: Value numbering and volatility
Eric Botcazou wrote on 06/21/06 10:05: > It seems to me that the volatility should be accounted for in the > VALUE_HANDLE > itself only, not in (de)references to it. > As Richard and Andrew pointed out, the bug is that we try to compute the value number of a statement with volatile references in it. If the statement is not marked as having volatile references, then it should be. If the value numbering routines are not checking for volatility, then they should be.
Re: Value numbering and volatility
Diego Novillo wrote:
> Eric Botcazou wrote on 06/21/06 10:05:
>
>> It seems to me that the volatility should be accounted for in the
>> VALUE_HANDLE
>> itself only, not in (de)references to it.
>>
> As Richard and Andrew pointed out, the bug is that we try to compute the
> value number of a statement with volatile references in it. If the
> statement is not marked as having volatile references, then it should
> be. If the value numbering routines are not checking for volatility,
> then they should be.
If the statement has volatile ops, we just give the defs the statement
makes (not the virtual defs) unique value numbers, as we should :)
if (TREE_CODE (stmt) == MODIFY_EXPR
&& !ann->has_volatile_ops
{
...
}
else
{
/* For any other statement that we don't recognize, simply
make the names generated by the statement available in
AVAIL_OUT and TMP_GEN. */
FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_DEF)
add_to_sets (op, op, NULL, TMP_GEN (block), AVAIL_OUT (block));
FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_USE)
add_to_sets (op, op, NULL, NULL , AVAIL_OUT (block));
}
Since he's showing us a indirect store or load (which won't show up in
the defs list of a statement) being value numbered, the statement must
not be marked has_volatile_ops properly.
>
Re: MIPS RDHWR instruction reordering
On 20 Jun 2006 09:10:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > Should I file a bug report? > > Yes, please. Thanks. Done. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126 --- Atsushi Nemoto
Re: [RFC] Optimization Diary
Hi, On Wed, 7 Jun 2006, Daniel Jacobowitz wrote: > On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote: > > And string does not answer localization issue, however for numbers at least > > there is one precedent to follow. > > I think this discussion has gotten totally sidetracked. When I said > I was in favor of strings, I didn't mean messages that would ever be > displayed! It's the difference between DW_TAG_compile_unit and > "compile-unit". > > It is no more work for the producer or for the consumer, it's clearer, > and conflicts are much less likely. The only downside is that it's > larger. Depending on how it's implemented (via direct encoding or indirect refs to a strings section) it can be much larger. Strings have their advantages, but just using them because of the perceived easyness to extend the identifier space ... I'm not sure that's a good idea. When you have several hundred .o files you care about debug info size. And string merging in the linker doesn't come for free either. It's slow enough already to link projects with large debug infos. In general I don't believe very much in strings used as tags or identifiers in things for consumption by machines. At least if the identifier space is controllable a bit. You either need string compares to identify them, or make a pass before hand unifying all strings so that you can use pointer compares. All the things which make it ugly and slow to have strings for machine consumption. A file-format with built-in slowness and bloat. Ciao, Michael. PS: And yes, I don't like XML :-) PPS: Yes, that comparison stinks.
i686-unknown-winnt target not defined
Hi , I have compiled binutils successfully with the target i686-unknown-winnt. But the make for gcc fails. It says target not supported. I think i can workaround it using i686-unknown-mingw32. Few questions 1) Is it a known feature or a bug or something that i am doing wrong ? 2) Do we have something for gcc like configure.tgt for ld and gas of bintutils. If yes what. 3) Any differences between the targets. If yes what are they THanks nik
Re: state of decimal float support in GCC
Janis Johnson wrote: > Support in GCC 4.2 for decimal floating types is based on drafts of > ISO/IEC WDTR 23732, which continues to change. There are some > differences between the most recent draft N1176 and what GCC implements, > and some other things that should probably change or at least be > documented. I'd appreciate some guidance on these. > > 1. The draft TR specifies that an implementation define __STDC_DEC_FP__ >as 1 to indicate conformance to the technical report. GCC currently >defines this, but there are a couple of issues here. First is that >GCC is only one piece of the implementation and the macro shouldn't >be defined unless the C library also implements the library portion. >The other issue is that the TR continues to change, and the macro >shouldn't be defined until GCC and the relevant C library support the >final version of the TR. I'd like to remove this from GCC, if it's >OK to do that at this late stage. That seems a good conservative change. (This same problem has arisen in past with some of the IEEE macros, in the opposite direction; GLIBC has defined them, even when the compiler doesn't provide the full guarantees.) I think the only way to get this 100% right is to provide a configure option to GCC that says whether or not to define the macro, but, even then, you have to be multilib-aware, as a uClibc multilib might not get the macro, even while a GLIBC multilib does get the macro. If the standards permit defining the macros in library headers (rather than requiring them to be pre-defined by the compiler), then an easier solution would be to have GCC define __GCC_DEC_FP__, and then have the library do: #ifdef __GCC_DEC_FP__ /* This library is DFP-capable, and GCC is DFP-capable, so... */ #define __STDC_DEC_FP__ #endif > 3. Earlier drafts specified that a new header file define >various macros for characteristics of decimal floating types. The >latest draft puts these in instead. I'm inclined to leave >them in until the TR is approved, or at least more >stable, and document that difference. The downside to that is that some people may want us to provide forever, for source compatibility with GCC 4.2. It's frustrating that we don't really know if/when the TR will actually be final; things might move again, for all we know. I think you should document the difference, and say that we expect to remove in a future release. I think your other documentation suggestions make sense. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
pretty-print.c and gettext
Hi, In gcc 4.1.0 the syntax of gcc-internal format strings - as defined in pretty-print.c - has been extended to support reordering of arguments (through the %n$ syntax). Now the Swedish translator of gcc.pot would like to make use of this feature, but the infrastructure is not yet in place. Currently parts of the translator's PO file are flagged as invalid, and msgmerge will disable these "invalid" parts. IMO the support needs to be installed in this order: 1) A gettext-0.14.6 is released is put out that supports the GCC 4.1 syntax of gcc-internal format strings. 2) The GCC team installs it on the machines it uses for creating GCC releases. 3) Then the Free Translation Project's robot is changed to use this release as well. Then the Swedish translator can resubmit his PO file; the TP robot will accept it and notify the GCC team; then the "msgmerge" program on your machines will handle the translation correctly. Step 1 is done: gettext-0.14.6 is on http://ftp.gnu.org/gnu/gettext/. Can you please proceed to step 2: ensure that the gettext-0.14.6 tools are used for building gcc-4.1.2 and newer? Bruno
Re: pretty-print.c and gettext
On Wed, 21 Jun 2006, Bruno Haible wrote: > Can you please proceed to step 2: ensure that the gettext-0.14.6 tools > are used for building gcc-4.1.2 and newer? To be clear, gettext tools are used in two ways in building new releases: * xgettext is run to update gcc.pot and cpplib.pot. * GCC is built with --enable-generated-files-in-srcdir, which uses msgfmt to create .gmo files and copy them into the source directory for packaging. Do you need new gettext versions to be used for both of these steps, or just one? Could you submit to gcc-patches appropriate refinements to the configure tests in config/po.m4 to enforce the use of sufficiently new gettext where required? (GCC maintainers don't run msgmerge; we download merged .po files from the TP website.) -- Joseph S. Myers [EMAIL PROTECTED]
Re: pretty-print.c and gettext
Joseph S. Myers wrote: > To be clear, gettext tools are used in two ways in building new releases: > > * xgettext is run to update gcc.pot and cpplib.pot. > > * GCC is built with --enable-generated-files-in-srcdir, which uses msgfmt > to create .gmo files and copy them into the source directory for > packaging. > > Do you need new gettext versions to be used for both of these steps, or > just one? I'm asking primarily for the second step. For the first step, I don't know whether it will make a difference: Format strings in the gcc source code certainly don't use reordering, and the other significant change (allowing the %J format directive in a place other than at the beginning of the format string) is not used in gcc-4.1.0. But for the future (4.2 etc.) it's certainly safer to use gettext-0.14.6 than -0.14.5. > (GCC maintainers don't run msgmerge; we download merged .po files from the > TP website.) OK, that's fine. Then you only need msgfmt from the gettext-0.14.6 package. > Could you submit to gcc-patches appropriate refinements to the > configure tests in config/po.m4 to enforce the use of sufficiently new > gettext where required? The files that mention 0.14.5 so far are gcc/doc/install.texi and gcc/po/exgettext. It's trivial to update these two to mention 0.14.6. You can do that. Bruno
