DEBUG_INSN that is not an insn
Hello, While browsing through the mailing list archives a bit, I noticed Alex's project to improve GCC's debug information. This seems like a really interesting and worthwhile project. Alex, maybe you could add a Wiki page about this project, in the style of http://gcc.gnu.org/wiki/SampleProjectTemplate ... ? I am worried about some of the things going on in the var-tracking-assignments branch. The thing that worries me most, is the introduction of an insn that is not an instruction: /* An annotation for variable assignment tracking. */ DEF_RTL_EXPR(DEBUG_INSN, "debug_insn", "iuuBieie", RTX_INSN) DEBUG_INSN is more like a note, AFAIU. I couldn't find any discussions about this idea, so I don't know if there is "sufficient" concensus that this is the right thing to do. IMHO, anything that is not an instruction should not be true under INSN_P. Yet, INSN_P returns true for DEBUG_INSN. This is already leading to a lot of special-casing of DEBUG_INSN throughout the RTL bits of the compiler on the branch. Also, registers mentioned in DEBUG_INSNs are counted as real uses, which is bound to confuse some existing RTL analyses, and makes it harder to implement new ones safely. The same issues arise with DEBUG_STMT for tree-ssa. Is this really a design that has the necessary support to make the branch eligible for merging into the trunk? What are the reasons for using a fake insn instead of a note for DEBUG_INSN? Thanks, Gr. Steven
Re: DEBUG_INSN that is not an insn
On 11/5/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: > Hello, > > While browsing through the mailing list archives a bit, I noticed > Alex's project to improve GCC's debug information. This seems like a > really interesting and worthwhile project. Alex, maybe you could add a > Wiki page about this project, in the style of > http://gcc.gnu.org/wiki/SampleProjectTemplate ... ? > > I am worried about some of the things going on in the > var-tracking-assignments branch. The thing that worries me most, is > the introduction of an insn that is not an instruction: > > /* An annotation for variable assignment tracking. */ > DEF_RTL_EXPR(DEBUG_INSN, "debug_insn", "iuuBieie", RTX_INSN) > > DEBUG_INSN is more like a note, AFAIU. I couldn't find any discussions > about this idea, so I don't know if there is "sufficient" concensus > that this is the right thing to do. > > IMHO, anything that is not an instruction should not be true under > INSN_P. Yet, INSN_P returns true for DEBUG_INSN. This is already > leading to a lot of special-casing of DEBUG_INSN throughout the RTL > bits of the compiler on the branch. > > Also, registers mentioned in DEBUG_INSNs are counted as real uses, > which is bound to confuse some existing RTL analyses, and makes it > harder to implement new ones safely. > > The same issues arise with DEBUG_STMT for tree-ssa. > > Is this really a design that has the necessary support to make the > branch eligible for merging into the trunk? What are the reasons for > using a fake insn instead of a note for DEBUG_INSN? No, I don't think so. Also, see http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00200.html for a different approach (ok, that's not the current state). For RTL we chose to extend SET by a bitmap argument featuring the debug symbols affected by this set. Richard.
Re: Why is this still not allowed by gcc while MSVC does(const template argument)
"Jun Chen" <[EMAIL PROTECTED]> writes:
> Please check the following small program:
This is the wrong mailing list. Please use [EMAIL PROTECTED] for
questions about using gcc. The mailing list gcc@gcc.gnu.org is for
developers of gcc itself. Please take any followups to
[EMAIL PROTECTED] Thanks.
> {code}
> t1.cpp:56: error: could not convert template argument '0' to 'MyClass*'
> t1.cpp:56: error: invalid type in declaration before ';' token
> t1.cpp: In function 'int main()':
> t1.cpp:63: error: invalid types 'CecMyClass[int]' for array subscript
> t1.cpp:64: error: invalid types 'CecMyClass[int]' for array subscript
> {code}
>
> I'm really baffled! Since 0 can be assigned to any pointer variable,
> then why "0 could not be converted to MyClass* "?
The C++ standard is clear: "Although 0 is a valid template-argument
for a non-type template-parameter of integral type, it is not a valid
template-argument for a non-type template-parameter of pointer type."
(14.3.2 Template non-type arguments [temp.arg.nontype]).
Ian
Re: GCC 4.3.0 Status Report (2007-11-04)
On Sun, Nov 04, 2007 at 07:32:07PM -0800, Mark Mitchell wrote: > > Questions > = > > * Does anyone object to turning on mapped locations by default? > > * Are there any unreviewed patches that I could help to review? > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00305.html and the libjava part in http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00842.html Thanks. H.J.
Documentation Error in Using the GNU Compiler Collection 4.2.1 & 4.3.0
GNU Compiler Collection Documentation Free Software Foundation Dear Sir or Madam: Today I found an error in versions 4.2.1 and 4.3.0 of Using the GNU Compiler Collection. Both versions have the same error. The error is at the very end of section 3.2 and is on page 21 of version 4.2.1 and page 25 of version 4.3.0. The error concerns what apparently is supposed to be the description of the @file option. Based on my knowledge of other compilers, it appears that the @file option is supposed to name a file that contains a list of compiler options. Instead of such a discussion, there are 16 lines of what is apparently LaTeX source code. Here is the content of the error. [Begin error text] %% %% This is file .tex, %% generated with the docstrip utility. %% %% The original source files were: %% %% fileerr.dtx (with options: return) %% %% This is a generated file. %% %% Copyright 1993 1994 1995 1996 1997 1998 1999 2000 %% The LaTeX3 Project and any individual authors listed elsewhere %% in this file. %% %% This file was generated from file(s) of the Standard LaTeX Tools Bundle. %% %% %% It may be distributed and/or modified under the %% conditions of the LaTeX Project Public License, either version 1.2 %% of this license or (at your option) any later version. %% The latest version of this license is in %% http://www.latex-project.org/lppl.txt %% and version 1.2 or later is part of all distributions of LaTeX %% version 1999/12/01 or later. %% %% This file may only be distributed together with a copy of the LaTeX %% Tools Bundle. You may however distribute the LaTeX Tools Bundle %% without such generated files. %% %% The list of all files belonging to the LaTeX Tools Bundle is %% given in the file manifest.txt. %% \messageFile ignored \endinput %% %% End of file .tex. /tmp/gcc-doc-update.17595/gcc/gcc/../libiberty/at-file.texi [End of error text] Please fix this error as soon as possible and replace it with the proper text. Also, when you fix this error, please include a complete description of how the @file option is supposed to work. What is the proper structure of such a file? Can it include comments? If so, how are those comments delimited? Please feel free to contact me at any time with any questions or concerns that you may have. Sincerely, Craig Dedo 17130 W. Burleigh Place P. O. Box 423 Voice Phone: (262) 783-5869 Brookfield, WI 53008-0423 Fax Phone: (262) 783-5928 USA Mobile Phone: (414) 412-5869 E-mail: <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
Re: GCC 4.3.0 Status Report (2007-11-04)
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00842.html I had already approved this. Paolo
Re: GCC 4.3.0 Status Report (2007-11-04)
On Mon, Nov 05, 2007 at 05:44:34PM +0100, Paolo Bonzini wrote: > >http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00842.html > > I had already approved this. > I missed it. I checked it in. Thanks. H.J.
Re: Extending jumps after block reordering
+++ Eric Botcazou [02/11/07 09:56 +0100]: > > Questions: > > * shorten_branches() computes sizes of instructions so I know what the > > distance is between a jump instr and its target label. But how do I know > > what is the maximum distance each kind of branch can safely take? > > bb-reorder.c assumes that its only when cold/hot partitions are crossed > > it has to use indirect jumps, which is not the appropriate test in my case. > > You cannot easily, it's buried in the architecture back-ends. > > > * do I get it right that shorten_branches() does not really modify > > instructions but it helps to shorten branches by providing more accurate > > insns lengths? > > Yes, but this should work automatically. IOW, as Ian said, you shouldn't > need > to do anything special. Maybe it's simply a latent bug in the PPC back-end. Got it working. It turns out I was renumbering the instructions just before pass_final and it was messing up the creation of jump islands in PPC (and I believe other archs with short cond branches). I changed my code not to require the renumbering and it's all working now. Thanks a lot, Gregory -- Gregory B. Prokopski <[EMAIL PROTECTED]> Sable Research Group http://www.sable.mcgill.ca Montreal, Quebec, Canada
RE: Documentation Error in Using the GNU Compiler Collection 4.2.1 & 4.3.0
On 05 November 2007 16:29, Craig Dedo wrote: > Today I found an error in versions 4.2.1 and 4.3.0 of Using the GNU > Compiler Collection. Both versions have the same error. > > The error is at the very end of section 3.2 and is on page 21 of > version 4.2.1 and page 25 of version 4.3.0. The error concerns what > apparently is supposed to be the description of the @file option. Based on > my knowledge of other compilers, it appears that the @file option is > supposed to name a file that contains a list of compiler options. Instead > of such a discussion, there are 16 lines of what is apparently LaTeX source > code. Thanks for the report, but I think the problem isn't in the gcc documentation source itself. I think someone must have gone wrong during the build and install process of whatever gcc package you were looking at. The error is not visible in the online documentation at the gcc website that is autogenerated from source code: both for 4.2 series: http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Overall-Options.html#Overall-Optio ns and for the latest (4.3) sources: http://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options Nor could I see it in the info files from my own installation, which I built from source code a little while ago. > Please fix this error as soon as possible and replace it with the > proper text. It seems that the bug only exists in your local copy. Precisely which form of the file were you looking at, and where did you get it from? Was it part of a Linux distribution? If so, you'd need to report it to the distro supplier. > Also, when you fix this error, please include a complete description > of how the @file option is supposed to work. What is the proper structure > of such a file? Can it include comments? If so, how are those comments > delimited? Check the description at those links I pointed you to, I hope you'll find it adequate. If not, we can easily extend it. cheers, DaveK -- Can't think of a witty .sigline today
Question regarding GCC fdump option
Hi I have a question regarding gcc or g++ -fdump-tree-all-raw-details (.tu file). I want to dump the entire C (not C++) AST tree the only way to do this, without losing any information, is if I use g++ and -fdump-tree-all-raw-details and i have some kind of error in the file. Can I in some way change a flag or edit a method in the source files so i can use this option without having an error in my c file but get all the information. Even better would be if i could use gcc. //Johan (using gcc 4.2.1)
Re: GCC 4.3.0 Status Report (2007-11-04)
Alexandre Oliva wrote: > On Nov 5, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > >> * Are there any unreviewed patches that I could help to review? > > Also, how about the patch for PR27898? > > http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00187.html Joseph, would you please review this patch? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: strict aliasing
skaller <[EMAIL PROTECTED]> writes:
> Can someone tell me what optimisations might be enabled/disabled
> by strict aliasing rules?
With no aliasing information at all, the compiler can not reorder load
and store instructions, because they might refer to the same memory
locations. The compiler does a bunch of analysis to determine whether
load and store instructions can refer to the same location. Strict
aliasing refers to one component of that analysis, really a final
tie-breaker: using type information to distinguish loads and stores.
> Is there some merit in a switch which allows coarse aliasing
> optimisations, that is, allows optimisations based on integer
> vs float vs pointer, but not on pointer vs pointer?
Strict aliasing only refers to loads and stores using pointers. So
presumably you mean permitted the alias analysis to distinguish loads
and stores using int* and float*, but not struct s* and struct t*. I
don't think that would be particularly useful.
> I have some code which makes aliases by pointer casting
> to layout compatible types: optimisations based on the
> type distinction would break the code. However aliasing
> on incompatible types (eg pointer to float vs int) are
> desired (rather -- I want the fastest possible code,
> without breaking my pointer cast hackery).
>
> BTW: one of the hacks is aliasing pairs like these:
>
> struct X { T x; X(T a) : x(x) {} };
> struct Y { T x[1]; };
>
> in C++, so a constructor can initialise an array
> of known length efficiently. (in C++ assignment
> of default initialised value can cost more than
> initialisation, and may even be impossible if
> there is no default constructor).
C (I don't know about C++) provides an out to the aliasing rules for
unions. Section 6.5.2.3 of the C standard:
One special guarantee is made in order to simplify the use of
unions: if a union contains several structures that share a common
initial sequence (see below), and if the union object currently
contains one of these structures, it is permitted to inspect the
common initial part of any of them anywhere that a declaration of
the complete type of the union is visible. Two structures share a
common initial sequence if corresponding members have compatible
types (and, for bit-fields, the same widths) for a sequence of one
or more initial members.
Note that this applies anywhere that a declaration of the complete
type of the union is available. That is, it does not only apply to
accesses through pointers to the union type. This imposes some
significant restrictions on alias analysis of pointers to structs.
Ian
Re: strict aliasing
On Mon, 2007-11-05 at 09:56 -0800, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > Can someone tell me what optimisations might be enabled/disabled
> > by strict aliasing rules?
> Strict aliasing only refers to loads and stores using pointers.
Ah, I see. So turning it off isn't really all that bad
for optimisation.
> So
> presumably you mean permitted the alias analysis to distinguish loads
> and stores using int* and float*, but not struct s* and struct t*. I
> don't think that would be particularly useful.
No, that wasn't what I meant .. it seems that the existing
switch already does what I want!
> > BTW: one of the hacks is aliasing pairs like these:
> >
> > struct X { T x; X(T a) : x(x) {} };
> > struct Y { T x[1]; };
> >
> > in C++, so a constructor can initialise an array
> > of known length efficiently. (in C++ assignment
> > of default initialised value can cost more than
> > initialisation, and may even be impossible if
> > there is no default constructor).
>
> C (I don't know about C++) provides an out to the aliasing rules for
> unions.
Due to stupidity on the part of WG21, this won't work for the above
code because X above has a constructor, and unions may not
contain constructable types. [Excuse my annoyance -- I vetoed this
as an NB representative, but the current rule was passed next
meeting which I could afford to attend]
--
John Skaller
Felix, successor to C++: http://felix.sf.net
Re: strict aliasing
skaller <[EMAIL PROTECTED]> writes: > On Mon, 2007-11-05 at 09:56 -0800, Ian Lance Taylor wrote: > > skaller <[EMAIL PROTECTED]> writes: > > > > > Can someone tell me what optimisations might be enabled/disabled > > > by strict aliasing rules? > > > Strict aliasing only refers to loads and stores using pointers. > > Ah, I see. So turning it off isn't really all that bad > for optimisation. It depends on the processor. For an in-order processor with a deep pipeline (e.g., Itanium, but there are others), the ability to reorder loads and stores is very important to permit scheduling flexibility. Strict aliasing reportedly makes a difference for x86, but I don't think it makes a huge difference. Ian
Re: strict aliasing
On Mon, Nov 05, 2007 at 10:15:55AM -0800, Ian Lance Taylor wrote: > skaller <[EMAIL PROTECTED]> writes: > > Ah, I see. So turning [strict aliasing] off isn't really all that bad > > for optimisation. > > It depends on the processor. For an in-order processor with a deep > pipeline (e.g., Itanium, but there are others), the ability to reorder > loads and stores is very important to permit scheduling flexibility. > Strict aliasing reportedly makes a difference for x86, but I don't > think it makes a huge difference. It also depends on the input: for scientific codes that process both integer and real data, strict aliasing could make a large difference on any processor.
Re: strict aliasing
On Mon, 2007-11-05 at 10:15 -0800, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > On Mon, 2007-11-05 at 09:56 -0800, Ian Lance Taylor wrote:
> > > skaller <[EMAIL PROTECTED]> writes:
> > >
> > > > Can someone tell me what optimisations might be enabled/disabled
> > > > by strict aliasing rules?
> >
> > > Strict aliasing only refers to loads and stores using pointers.
> >
> > Ah, I see. So turning it off isn't really all that bad
> > for optimisation.
>
> It depends on the processor. For an in-order processor with a deep
> pipeline (e.g., Itanium, but there are others), the ability to reorder
> loads and stores is very important to permit scheduling flexibility.
> Strict aliasing reportedly makes a difference for x86, but I don't
> think it makes a huge difference.
Well, I have been compiling with strict-aliasing enabled and
haven't encountered any errors that I'm aware of: the code seems
to run on x86, x86_64 and PPC32. I do get a couple of warnings.
In the example case, the code looks like:
reinterpret(X(1,2,3))
where re-interpret is:
template
T &reinterpret(U const &x) {
return reinterpret_cast(const_cast(x));
}
This is pretty nasty, but is necessary to work around
design faults in C++.
It's essential here that the X struct be initialised before
any loads via the Y struct (any reordering would be a disaster).
g++ seems to generate the right code here, but the warning
does worry me. There are some other breaches -- essential with
a custom memory manager (Felix has a garbage collector),
however I think they're no problem due to enough subroutine
boundaries getting in the way :)
--
John Skaller
Felix, successor to C++: http://felix.sf.net
Re: GCC 4.3.0 Status Report (2007-11-04)
On Mon, 5 Nov 2007, Mark Mitchell wrote: > Alexandre Oliva wrote: > > On Nov 5, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > > >> * Are there any unreviewed patches that I could help to review? > > > > Also, how about the patch for PR27898? > > > > http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00187.html > > Joseph, would you please review this patch? It seems OK to me unless Geoff Keating sees anything wrong as the -combine expert. -- Joseph S. Myers [EMAIL PROTECTED]
Re: strict aliasing
On Mon, 2007-11-05 at 10:20 -0800, Joe Buck wrote: > On Mon, Nov 05, 2007 at 10:15:55AM -0800, Ian Lance Taylor wrote: > > skaller <[EMAIL PROTECTED]> writes: > > > Ah, I see. So turning [strict aliasing] off isn't really all that bad > > > for optimisation. > > > > It depends on the processor. For an in-order processor with a deep > > pipeline (e.g., Itanium, but there are others), the ability to reorder > > loads and stores is very important to permit scheduling flexibility. > > Strict aliasing reportedly makes a difference for x86, but I don't > > think it makes a huge difference. > > It also depends on the input: for scientific codes that process both > integer and real data, strict aliasing could make a large difference > on any processor. Hmm .. the problem is that C is fairly brain dead, and people regularly use casts: strict aliasing almost seems to break a fundamental feature of the language. [Hmm .. how strict is it? int* and unsigned* have to be aliased, there's even a rule that guarantees that for the common subset of values the representation is the same (that rule would be useless if you couldn't alias an int and an unsigned!) Similarly for const. pointers to pointer and intptr_t is another one used heavily] -- John Skaller Felix, successor to C++: http://felix.sf.net
Re: Tree-SSA and POST_INC address mode inompatible in GCC4?
On Sunday 04 November 2007, Mark Mitchell wrote: > Kenneth Zadeck wrote: > > To fix this will require a round of copy propagation, most likely in > > concert with some induction variable detection, since the most > > profitable place for this will be in loops. > > For code size, it will be profitable everywhere. On ARM Not technically true. On Thumb-2 we have variable length instruction encoding. For small offsets (< 16bytes IIRC) a pair of post increment loads is larger than a pair of offset loads and an add. However using postincrement everywhere is a good start (probably better than what we have) and I'd guess is a prerequisite for adding more advanced cost heuristics. Paul
Re: strict aliasing
Ian Lance Taylor wrote:
> Strict aliasing only refers to loads and stores using pointers.
skaller writes:
> Ah, I see. So turning it off isn't really all that bad
> for optimisation.
One example of where it hurts on just about any platform is something
like this:
void allocate(int **p, unsigned len);
int *foo(unsigned len) {
int *p;
unsigned i;
allocate(&p, len);
for (i = 0; i < len; i++)
p[i] = 1;
return p;
}
Without strict aliasing being enabled, the compiler can't assume that
that the assignment "p[i] = 1" won't change "p". This results the value
of p being loaded on every loop iteration, instead of just once at the
start of the loop. It also prevents GCC from vectorizing the loop.
On Itaninum CPUs speculative loads can be used instead of strict alias
analysis to avoid this problem.
Ross Ridge
Re: strict aliasing
On Tue, Nov 06, 2007 at 05:44:44AM +1100, skaller wrote: > > On Mon, 2007-11-05 at 10:20 -0800, Joe Buck wrote: > > On Mon, Nov 05, 2007 at 10:15:55AM -0800, Ian Lance Taylor wrote: > > > skaller <[EMAIL PROTECTED]> writes: > > > > Ah, I see. So turning [strict aliasing] off isn't really all that bad > > > > for optimisation. > > > > > > It depends on the processor. For an in-order processor with a deep > > > pipeline (e.g., Itanium, but there are others), the ability to reorder > > > loads and stores is very important to permit scheduling flexibility. > > > Strict aliasing reportedly makes a difference for x86, but I don't > > > think it makes a huge difference. > > > > It also depends on the input: for scientific codes that process both > > integer and real data, strict aliasing could make a large difference > > on any processor. > > Hmm .. the problem is that C is fairly brain dead, and people > regularly use casts: strict aliasing almost seems to break > a fundamental feature of the language. Strict aliasing has been the rule since 1989 and is a fundamental feature. Many programmers believe that they can cast with abandon, but this is not the case. > [Hmm .. how strict is it? int* and unsigned* have to be aliased, > there's even a rule that guarantees that for the common subset > of values the representation is the same (that rule would be > useless if you couldn't alias an int and an unsigned!) This isn't the place to teach people the exact rule; it's in the standard. As you say, the unsigned and signed versions of integral types can alias.
gcc-4.1-20071105 is now available
Snapshot gcc-4.1-20071105 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071105/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 129910 You'll find: gcc-4.1-20071105.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20071105.tar.bz2 C front end and core compiler gcc-ada-4.1-20071105.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20071105.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20071105.tar.bz2 C++ front end and runtime gcc-java-4.1-20071105.tar.bz2 Java front end and runtime gcc-objc-4.1-20071105.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20071105.tar.bz2The GCC testsuite Diffs from 4.1-20071029 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC 4.3.0 Status Report (2007-11-04)
H.J. Lu wrote: > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00305.html OK. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: DEBUG_INSN that is not an insn
> I am worried about some of the things going on in the > var-tracking-assignments branch. The thing that worries me most, is > the introduction of an insn that is not an instruction: > > /* An annotation for variable assignment tracking. */ > DEF_RTL_EXPR(DEBUG_INSN, "debug_insn", "iuuBieie", RTX_INSN) > > DEBUG_INSN is more like a note, AFAIU. I couldn't find any discussions > about this idea, so I don't know if there is "sufficient" concensus > that this is the right thing to do. > > IMHO, anything that is not an instruction should not be true under > INSN_P. Yet, INSN_P returns true for DEBUG_INSN. This is already > leading to a lot of special-casing of DEBUG_INSN throughout the RTL > bits of the compiler on the branch. I share your concerns, but I've not looked at the specifics. -- Eric Botcazou
Wrong ChangeLog entry in gcc/ChangeLog
Hi Paul, Did you check the wrong ChangeLog entry in gcc/ChangeLog with http://gcc.gnu.org/viewcvs?view=rev&revision=129904 H.J.
Re: GCC 4.3.0 Status Report (2007-11-04)
On Sun, Nov 04, 2007 at 07:32:07PM -0800, Mark Mitchell wrote: > > Questions > = > > * Does anyone object to turning on mapped locations by default? > > * Are there any unreviewed patches that I could help to review? > Another one http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01865.html which involves reload. H.J.
Re: GCC 4.3.0 Status Report (2007-11-04)
H.J. Lu wrote: > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01865.html > > which involves reload. I'm not going to try to wade into reload. Ulrich, Eric, Ian -- would one of you please review this patch? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-11-04)
Alexandre Oliva wrote: > http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00608.html > > Without this patch, -g changes the generated code quite often. This is OK, assuming no objections within 24 hours. As previously discussed, maintaining identical output with and without -g is a design goal for GCC, so when we find problems like this, we need to fix them, even if there's some memory cost. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: strict aliasing
On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote:
> Ian Lance Taylor wrote:
> > Strict aliasing only refers to loads and stores using pointers.
>
> skaller writes:
> > Ah, I see. So turning it off isn't really all that bad
> > for optimisation.
>
> One example of where it hurts on just about any platform is something
> like this:
>
> void allocate(int **p, unsigned len);
>
> int *foo(unsigned len) {
> int *p;
> unsigned i;
> allocate(&p, len);
> for (i = 0; i < len; i++)
> p[i] = 1;
> return p;
> }
>
> Without strict aliasing being enabled, the compiler can't assume that
> that the assignment "p[i] = 1" won't change "p". This results the value
> of p being loaded on every loop iteration, instead of just once at the
> start of the loop. It also prevents GCC from vectorizing the loop.
Now I'm a bit confused.. Ian wrote previously:
" Strict
aliasing refers to one component of that analysis, really a final
tie-breaker: using type information to distinguish loads and stores."
and
"Strict aliasing only refers to loads and stores using pointers."
but the assignment here is of an int. My understanding was that
this is "non-strict" aliasing rule, so the optimisation could
still be applied: storing an int cannot change a pointer.
Had the data type been a T* for some T, then it might have
been an alias to an int*, and I would see it.
This distinction appears to matter quite a bit, particularly
in light of Joe's comment:
"for scientific codes that process both
integer and real data, strict aliasing could make a large difference
on any processor."
It's kind of messy because array names are almost but not
quite pointers. Curious how C++ references are handled?
If we change the above code to use
int &p
then presumably p is modelled by a pointer anyhow, however
it can't be modified by aliasing because the 'pointer p'
is a constant.
> On Itaninum CPUs speculative loads can be used instead of strict alias
> analysis to avoid this problem.
Can't you use a read prefetch instruction in a similar way
on an amd_64? [Not the same thing .. better actually since
it doesn't commit a register]
--
John Skaller
Felix, successor to C++: http://felix.sf.net
