Re: GCC 4.2 Status Report (2006-06-04)
Joern RENNECKE wrote: In http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html, you wrote: As fwprop is no longer on the table for 4.2, and as the vectorizer improvements seem to have stalled due to a combination of lack of review and Dorit's leave, I think it's time to declare 4.2 feature-complete. I am still waiting for review of by auto-increment patches, and for Berndt to complete the cross-jump part struct-equiv patches, so that I can post an updated patch for the if-conversion part. At this point I think it's better to wait for 4.3. I like neither of the current proposed solutions - mine costs too much compile time, while yours is too much of a hack. A while back I did some CSiBE testing that did not show enough benefit for the loss of compile time. We need to figure out something better. Bernd
Re: Fw: GCC 4.2 Status Report (2006-06-04)
> This status report has been a long time coming, for which I apologize. > > As fwprop is no longer on the table for 4.2, and as the vectorizer > improvements seem to have stalled due to a combination of lack of review > and Dorit's leave, That is unfortunate. Dorit did make a sincere effort to prepare her patches long ago (mid February) well before leaving, and Victor has been constantly pinging for reviews, ready to address them. Ayal. > I think it's time to declare 4.2 feature-complete. > > That leaves us looking at regressions. There are lots; presently 56 > P1s. About half of those are new in 4.2. So, we're not ready to create > a 4.2 branch. > > Therefore, we need to make the mainline open for regression-fixes only > to force ourselves to attack the open bugs. Please consider the > mainline operating under release-branch rules as of 12:01 AM Wednesday, > California time. That will give everyone a few days to check in any > in-progress bug-fixes that are not regressions. > > At this time, I don't think it makes sense to set a 4.2 target branch > date. We have to see how fast the bug-fixing goes. > > -- > Mark Mitchell > CodeSourcery > [EMAIL PROTECTED] > (650) 331-3385 x713
Re: Modifying ARM code generator for elimination of 8bit writes - need help
Wolfgang Mües <[EMAIL PROTECTED]> writes:
> On Sunday 04 June 2006 23:36, Rask Ingemann Lambertsen wrote:
>> On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
>> > > (define_insn "*arm_movqi_insn"
>> > > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m")
>> > > (match_operand:QI 1 "general_operand" "rI,K,m,r"))]
>
>> I think you should go back to this (i.e. the unmodified version) and
>> only change the "m" into "Q" in the fourth alternative of operand 0.
>> See if that works, i.e. generates addresses that are valid for the
>> swp instruction.
>
> No, that doesn't work:
>
>> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c: In function
>> __register_frame_info_table_bases':
>> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: error: insn does not
>> satisfy its constraints: (insn 63 28 29 0
>> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:136 (set (mem/s/j:QI (plus:SI
>> (reg/v/f:SI 1 r1 [orig:102 ob ] [102]) (const_int 16 [0x10])) [0 S1
>> A32])
>> (reg:QI 12 ip)) 155 {*arm_movqi_insn} (nil)
>> (nil))
>> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: internal compiler error:
>> in reload_ cse_simplify_operands, at postreload.c:391
This is just a guess, but the insn above might be an output reload.
Reload instructions are not themselves reloaded. In other words,
if gcc needs to reload a QImode register out to a memory location,
it will assume that any m<-r move is OK; it will not restrict the
reload to Q<-r. This is by design. You can:
(1) Trap this in the movqi expander, if you can fix up the general
case without clobbering additional registers (unlikely).
(2) Define a reload_outqi pattern to handle general m<-r moves.
You then get a scratch register to play with. (This interface
has changed (and improved) since I last used it.)
(3) Modify reload so that output memory operands are legitimised
differently (only if you're brave).
(4) Restrict QImode addresses to 'Q'.
It looks downthread like you've already decided to do (4). I just
wasn't sure from the thread whether you realised that output reloads
might be a specific problem. Sorry in advance if this was just noise. ;)
Richard
Re: [MinGW] Set NATIVE_SYSTEM_HEADER_DIR relative to configured prefix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ross Ridge wrote:
> Ranjit Mathew wrote:
>> Danny, I'm using the same configure flags that you have used for GCC
>> 3.4.5 MinGW release (*except* for --prefix=/mingw, which is something
>> like --prefix=/j/mingw/mgw for me), but the GCC I get is not relocatable
>> at all, while I can put the MinGW GCC 3.4.5 release anywhere on the
>> filesystem and it still works. :-(
>
> The GCC I get from my native MinGW build of the trunk is relocatable:
Curiouser and curiouser!
See the following output that shows what I was talking about
("TEMP" is set to "C:\TEMP", so "/tmp" is mapped to "C:\TEMP"):
- -- 8< --
C:\TEMP\mgw>c:\temp\mgw\mymingw\bin\gcc -v hello.c
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc/configure --prefix=/tmp/mgw/mymingw --host=i686-pc-mingw
32 --target=i686-pc-mingw32 --disable-nls --disable-checking --disable-debug --e
nable-threads=win32 --disable-win32-registry --enable-languages=c --disable-werr
or
Thread model: win32
gcc version 4.2.0 20060606 (experimental)
c:/temp/mgw/mymingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/cc1.exe -quiet -v
- -iprefix c:\temp\mgw\mymingw\bin\../lib/gcc/i686-pc-mingw32/4.2.0/ hello.c
-quie
t -dumpbase hello.c -mtune=generic -auxbase hello -version -o C:\TEMP/ccuw.s
ignoring nonexistent directory "/tmp/mgw/mymingw/include"
ignoring nonexistent directory "C:/TEMP/mgw/mymingw/i686-pc-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/include
C:/TEMP/mgw/mymingw/include
C:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0/include
End of search list.
GNU C version 4.2.0 20060606 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.2.0 20060606 (experimental).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129918
Compiler executable checksum: fa3ae888985b8ab892ffd388ea6c3279
c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../../i686-pc-mi
ngw32/bin/as.exe -o C:\TEMP/ccOS.o C:\TEMP/ccuw.s
c:/temp/mgw/mymingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/collect2.exe -Bdyn
amic c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../crt2.o -L
c:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0 -Lc:/temp/mgw/mymingw/b
in/../lib/gcc -LC:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0 -Lc:/temp/mgw/
mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../../../i686-pc-mingw32/lib -LC
:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0/../../../../i686-pc-mingw32/lib
-Lc:/temp/mgw/mymingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/../../.. -LC:/TEMP/m
gw/mymingw/lib/gcc/i686-pc-mingw32/4.2.0/../../.. C:\TEMP/ccOS.o -lmingw32 -
lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmi
ngw32 -lgcc -lmoldname -lmingwex -lmsvcrt
C:\TEMP\mgw>move mymingw yourmingw
1 file(s) moved.
C:\TEMP\mgw>c:\temp\mgw\yourmingw\bin\gcc -v hello.c
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc/configure --prefix=/tmp/mgw/mymingw --host=i686-pc-mingw
32 --target=i686-pc-mingw32 --disable-nls --disable-checking --disable-debug --e
nable-threads=win32 --disable-win32-registry --enable-languages=c --disable-werr
or
Thread model: win32
gcc version 4.2.0 20060606 (experimental)
c:/temp/mgw/yourmingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/cc1.exe -quiet -
v -iprefix c:\temp\mgw\yourmingw\bin\../lib/gcc/i686-pc-mingw32/4.2.0/ hello.c -
quiet -dumpbase hello.c -mtune=generic -auxbase hello -version -o C:\TEMP/ccktaa
aa.s
ignoring nonexistent directory "C:/TEMP/mgw/mymingw/include"
ignoring nonexistent directory "/tmp/mgw/mymingw/include"
ignoring nonexistent directory "C:/TEMP/mgw/mymingw/lib/gcc/i686-pc-mingw32/4.2.
0/include"
ignoring nonexistent directory "C:/TEMP/mgw/mymingw/i686-pc-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:/temp/mgw/yourmingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/include
End of search list.
GNU C version 4.2.0 20060606 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.2.0 20060606 (experimental).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129918
Compiler executable checksum: fa3ae888985b8ab892ffd388ea6c3279
hello.c:1:19: error: stdio.h: No such file or directory
hello.c: In function 'main':
hello.c:5: warning: incompatible implicit declaration of built-in function 'prin
tf'
C:\TEMP\mgw>
- -- 8< --
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT
Re: Fw: GCC 4.2 Status Report (2006-06-04)
On 6/6/06, Ayal Zaks <[EMAIL PROTECTED]> wrote: > This status report has been a long time coming, for which I apologize. > > As fwprop is no longer on the table for 4.2, and as the vectorizer > improvements seem to have stalled due to a combination of lack of review > and Dorit's leave, That is unfortunate. Dorit did make a sincere effort to prepare her patches long ago (mid February) well before leaving, and Victor has been constantly pinging for reviews, ready to address them. Maybe you can look at some of the regressions of the vectorizer first, instead of adding new features without first addressing regressions? This could build up some trust that the newly added code will actually be maintained in the future. For a quick bugzilla search, use the 4.2 regressions link on the gcc.gnu.org page and modify it to include "-ftree-vectorize" in the bug description. I count 3 P1 and 3 P2 regressions. Richard.
Re: ARM gcc 4.1 optimization bug.
Fengwei Yin wrote: Hi Daniel, I have already reported this bug. The bug number is #27363. I also tried the gcc snapshot 4.1.1-20060421. The bug is not fixed in this version too. > On 5/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote: > I am using gcc4.1 for ARM to build Linux kernel. But there is a bug > related to the gcc > optimization. I assume this is correct mail list to report this bug. > If not, please let me know. No, if you have a bug report, please use the bug reporting system. Please see: http://gcc.gnu.org/bugs.html Any news regarding this? Seems that I have the same problem. However, I first selected an other list http://sourceware.org/ml/crossgcc/2006-06/msg00032.html before finding this ;) Looking at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363 it looks to me that this isn't fixed at 4.1.1? To create "easier" testcase, maybe it helps to compile only kernel's sound modules? I can reproduce this failure compiling sound modules of 2.6.17-rc5 with using different optimization levels for them: -Os -> failure -O2 -> failure -O0 -> building of some modules fails -O1 -> sound works! Best regards Dirk
Re: ARM gcc 4.1 optimization bug.
On Tue, 2006-06-06 at 15:05, Dirk Behme wrote: > Fengwei Yin wrote: > > Hi Daniel, > > I have already reported this bug. The bug number is #27363. > > I also tried the gcc snapshot 4.1.1-20060421. The bug is not > > fixed in this version too. > > > > On 5/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > >> On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote: > >> > I am using gcc4.1 for ARM to build Linux kernel. But there is a bug > >> > related to the gcc > >> > optimization. I assume this is correct mail list to report this bug. > >> > If not, please let me know. > >> > >> No, if you have a bug report, please use the bug reporting system. > >> Please see: > >> http://gcc.gnu.org/bugs.html > > Any news regarding this? > > Seems that I have the same problem. However, I first > selected an other list > > http://sourceware.org/ml/crossgcc/2006-06/msg00032.html > > before finding this ;) > > Looking at > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363 > > it looks to me that this isn't fixed at 4.1.1? The bug is in state 'WAITING', which means there is not enough information for us to investigate the problem. See http://gcc.gnu.org/bugs.html for details of what we need. R.
RE: ARM gcc 4.1 optimization bug.
On 06 June 2006 15:17, Richard Earnshaw wrote: > On Tue, 2006-06-06 at 15:05, Dirk Behme wrote: >> Fengwei Yin wrote: >>> Hi Daniel, >>> I have already reported this bug. The bug number is #27363. >>> I also tried the gcc snapshot 4.1.1-20060421. The bug is not >>> fixed in this version too. >> > >>> On 5/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote: > I am using gcc4.1 for ARM to build Linux kernel. But there is a bug > related to the gcc optimization. I assume this is correct mail list to > report this bug. If not, please let me know. No, if you have a bug report, please use the bug reporting system. Please see: http://gcc.gnu.org/bugs.html >> >> Any news regarding this? >> >> Seems that I have the same problem. However, I first selected an other list >> >> http://sourceware.org/ml/crossgcc/2006-06/msg00032.html >> >> before finding this ;) >> >> Looking at >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363 >> >> it looks to me that this isn't fixed at 4.1.1? > > > The bug is in state 'WAITING', which means there is not enough > information for us to investigate the problem. > > See http://gcc.gnu.org/bugs.html for details of what we need. > > R. Just to elaborate: we need a simple self-contained testcase that anybody can compile themselves and see the bug. There's no possible way to analyze and fix it without being able to recreate it! In the bug report, you wrote "I tried to make a simple test example for this bug. But If I put the code from ALSA subsystem of Linux kernel to a test.c file, the gcc will product correct assembly code." So, what you need to do is re-do the original kernel build, but add "--save-temps" to the compiler flags, then find the .i file with the preprocessed source code for the failing module. This will be entirely selfcontained and will reproduce the bug, because that's what the compiler actually gets fed with in the case where you do see the bug; when you extracted it to a separate file there was probably some subtle difference related maybe to macro #defines or something that didn't match up. cheers, DaveK -- Can't think of a witty .sigline today
Inline memcpy in GCC 4.1.1
Hi, I'm updating a port from 3.4.6 to 4.1.1. In 3.4.6, I hadn't implemented movmemsi patterns, but the compiler could still inline memcpy's (and also strcpys where source string is a const) by itself. After updating to 4.1.1, calls to memcpy are always generated. I've had a bash at implementing movmemsi, but in a test case that does a strcpy (dest, "const"), it appears the 4th parameter (alignment) is always 1, and doing a MEM_ALIGN on the source operand results in 8, despite the fact I have implemented the CONSTANT_ALIGNMENT and DATA_ALIGNMENT macros to ensure that STRING_CSTs and QImode ARRAY_TYPEs get implemented on a BITS_PER_WORD boundary (If I look at the assembler output, then that shows the string being aligned as expected on a word boundary). So, two questions: any idea why 4.1.1 is no longer able to automatically inline memcpys and why is the source operand for movmemsi not know to be as widely aligned as it actually is? Cheers, Jon
Build report for AIX 5.1
Hi, i just built GCC 4.1.1 on AIX 5.1 using the following commands: ../gcc-4.1.1/configure --with-libiconv-prefix=/usr --disable-nls --disable-multilib make bootstrap-lean make install $ config.guess powerpc-ibm-aix5.1.0.0 $ gcc -v Using built-in specs. Target: powerpc-ibm-aix5.1.0.0 Configured with: /home/linke/temp/gcc-4.1.1/configure --with-libiconv-prefix=/usr --disable-nls --disable-multilib Thread model: aix gcc version 4.1.1 The system is an IBM pSeries M80 with AIX 5.1 at the latest patchlevel. The building c-complier is gcc 4.1.0 Make is gnu-make 3.80 The disable-xxx configure-options shouldn't be necessary, i used them for buildtime- and space-saving reasons. The whole build took less than two hours. Mario Linke
Re: Intermixing powerpc-eabi and powerpc-linux C code
You make a good point about the linker aspect but I was first most concerned about the code generation differences, if any. However, you are absolutely correct! A test is in order. I whipped up a quick test program and was able to successfully compile, link and run it, so it does indeed work! Thanks! On Thu, Jun 01, 2006 at 04:08:14PM -0700, Mike Stump wrote: > This is a linker question, we don't do linkers here. In particular, > the relocs have to be compatible, if you want to do reloc processing. > You can use ld and resolve all the relocs and just slam in the bytes, > but then, you're not using gcc to link per se. > > Why not just try it out and see?
RE: ARM gcc 4.1 optimization bug.
On 06 June 2006 15:33, Dave Korn wrote: > In the bug report, you wrote "You" being Fengwei Yin, of course, not Dirk Behme; apologies for my unclear attribution. cheers, DaveK -- Can't think of a witty .sigline today
Fw: GCC SC request about ecj
oops! forgot to cc the list. thanks Per. - Forwarded Message From: Per Bothner <[EMAIL PROTECTED]> To: Davanum Srinivas <[EMAIL PROTECTED]> Sent: Tuesday, June 6, 2006 11:49:23 AM Subject: Re: GCC SC request about ecj Davanum Srinivas wrote: > Please see http://www.eclipsezone.com/eclipse/forums/t71850.html > > "wget http://www.eclipse.org/jdt/core/patches/ecj_3.2RC3.jar";; should be > enough. Did you mean to send this to the mailing list? If you want to be anonymous, I can post it for you. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: which cctool on Darwin?
Shantonu, Thanks for the reply. I already figured out last night that I could use the odcctools cvs to generate a new odcctools tarball based on cctools-590.42.1. I was able to create an updated fink odcctools package using that tarball. I am bothering with this issue because I have noticed that if I have fink sourced while I build gcc trunk manually from the tarball that I see a slew of g++ regressions. These regressions are identical to those reported by Bradley Lucier... http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00221.html The regressions occur even if I build gcc trunk with the fink odcctools package deinstalled (so that the Xcode 2.3 cctools is used). Interestingly, if I build gcc trunk with fink not being sourced, the resulting build passes its g++ testsuite properly. Furthermore, I can source fink after gcc trunk is built and the g++ regressions don't show up. So the problem appears to be a conflict with something installed by fink that only occurs during the gcc trunk build itself. Shantonu, what sort of testsuite results do you get for opendarwin when you build gcc trunk? It would be nice to get a handle on why some of us are seeing these odd g++ failures. In my case, they seem to be tethered to something installed by fink but I am having a difficult time pinning it down. At first I thought it might be the setting of MACOSX_DEPLOYMENT_TARGET but that should only be set when building packages using fink itself and not set just because fink is sourced. Jack ps From my conversation with Geoff, I believe with the latest cctools, we should be able to build gcc trunk on a G5 now without resorting to the --disable-multilib hack.
Re: Inline memcpy in GCC 4.1.1
In http://gcc.gnu.org/ml/gcc/2006-06/msg00185.html, your wrote: So, two questions: any idea why 4.1.1 is no longer able to automatically inline memcpys and why is the source operand for movmemsi not know to be as widely aligned as it actually is? See PR middle-end/27226
Re: Recent VCG changes break gfortran's -std=f95 option
On Tue, Jun 06, 2006 at 08:16:54AM +0200, FX Coudert wrote:
>
> >>Something is marking random_seed as noreturn.
> >
> >As far as I understand, symbols are marked as noreturn by use of
> >TREE_THIS_VOLATILE, which is done on a few selected trees and is
> >also done whenever a symbol has the noreturn attribute. This
> >noreturn attribute can be set to 1 by make_noreturn, but nothing
> >ever sets it to 0, which is probably why we're experiencing this
> >problem.
> >
> >I have to go and not enough time to check it in detail, but perhaps
> >we should change that here:
>
> Index: intrinsic.c
> ===
> --- intrinsic.c (revision 114340)
> +++ intrinsic.c (working copy)
> @@ -254,6 +254,7 @@
>next_sym->resolve = resolve;
>next_sym->specific = 0;
>next_sym->generic = 0;
> + next_sym->noreturn = 0;
>break;
> default:
This patch is incorrect. The problem is that the make_noreturn()
calls in add_subroutine are attached to the immediately preceding
symbol name that is stuck in the list of intrinsics. In the case
of -std=f95 and random_seed(), the three intervening routine are
GFC_STD_GNU, so the make_noreturn() is applied to the wrong name.
Andrew and FX thanks for pointing me in the right direction.
If no one objects, I'll apply the enclosed patch later today.
2006-06-06 Steven G. Kargl <[EMAIL PROTECTED]>
* intrinsic.c (add_subroutine): Make make_noreturn() conditional on
the appropriate symbol name.
--
Steve
Index: intrinsic.c
===
--- intrinsic.c (revision 114435)
+++ intrinsic.c (working copy)
@@ -2232,7 +2232,8 @@ add_subroutines (void)
add_sym_0s ("abort", 1, GFC_STD_GNU, NULL);
- make_noreturn();
+ if ((gfc_option.allow_std & GFC_STD_GNU) || gfc_option.flag_all_intrinsics)
+make_noreturn();
add_sym_1s ("cpu_time", 0, 1, BT_UNKNOWN, 0, GFC_STD_F95,
gfc_check_cpu_time, NULL, gfc_resolve_cpu_time,
@@ -2338,7 +2339,8 @@ add_subroutines (void)
gfc_check_exit, NULL, gfc_resolve_exit,
c, BT_INTEGER, di, OPTIONAL);
- make_noreturn();
+ if ((gfc_option.allow_std & GFC_STD_GNU) || gfc_option.flag_all_intrinsics)
+make_noreturn();
add_sym_3s ("fgetc", 0, 1, BT_UNKNOWN, 0, GFC_STD_GNU,
gfc_check_fgetputc_sub, NULL, gfc_resolve_fgetc_sub,
Re: [RFC] Optimization Diary
> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: Devang> This version removes internal radar numbers and replaces s/ Devang> DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. * Why put the optimization diary into the object file? Why not just have -Wdiary and print it along with all the warnings? (I'm sure there's an answer to this, it would just be nice if it were in the document...) * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms of text highlighting. Why have a separate code here for "dead code" instead of just marking a text region and having a new _msg value meaning "dead code"? * DW_AT_GNU_OD_category The last value is 0x 0016. That seems wrong, I think it should end in 0010. What are "action trails"? Why is the action bit needed? The example in the text seems wrong, since there is an explicit _msg value for "function is inlined", and multiple values for why a function might not be inlined. How would the user find out what parameter is referred to by a parameter manipulation hint? I don't see where this is recorded. * DW_AT_GNU_OD_msg I presume that GCC will somehow maintain the canonical values here. It seems important that there be a central process for registering these so that weird divergences don't crop up over time. Also perhaps a "vendor extension" range should be specified? In any case, the mechanisms here ought to be documented. A nit: * The first example is oddly formatted. The blue region encompasses an entire comment, but the salmon (? nice color choice :) region stops before the '*/'. And... surely the diary won't be marking text regions corresponding to comments anyway? I feel like I'm probably misunderstanding the point of this highlighting. Tom
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Tue, Jun 06, 2006 at 10:39:46AM +0100, Richard Sandiford wrote:
> Wolfgang Mües <[EMAIL PROTECTED]> writes:
> >> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c: In function
> >> __register_frame_info_table_bases':
> >> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: error: insn does not
> >> satisfy its constraints:
[cut]
> >> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: internal compiler error:
> >> in reload_ cse_simplify_operands, at postreload.c:391
>
> This is just a guess, but the insn above might be an output reload.
It is, in a peculiar (and not useful) way. Diffing the greg dump against
the lreg dump shows (using the example code I posted):
+(insn:HI 25 17 38 2 (set (reg:QI 3 r3)
+(reg:QI 3 r3 [110])) 158 {*arm_movqi_insn_swp} (nil)
+(nil))
-(insn:HI 25 17 36 2 (set (mem/s:QI (plus:SI (reg/v/f:SI 101 [ x ])
+(insn 38 25 36 2 (set (mem/s:QI (plus:SI (reg/v/f:SI 0 r0 [orig:101 x ]
+ [101])
(const_int 5 [0x5])) [0 .c2+0 S1 A8])
-(subreg:QI (reg:SI 110) 0)) 158 {*arm_movqi_insn_swp} (nil)
-(expr_list:REG_DEAD (reg:SI 110)
-(expr_list:REG_DEAD (reg/v/f:SI 101 [ x ])
-(nil
+(reg:QI 3 r3)) 158 {*arm_movqi_insn_swp} (nil)
+(nil))
I.e. change insn 25 to a nop and then add insn 38 as essentially a duplicate
of the original insn 25. I don't think reload was supposed to do that. The
documentation as well as comments in reload.c suggest that the address would
be loaded into a register. I'm running the code in a debugger to find out
why it doesn't happen.
> Reload instructions are not themselves reloaded. In other words,
> if gcc needs to reload a QImode register out to a memory location,
> it will assume that any m<-r move is OK; it will not restrict the
> reload to Q<-r. This is by design. You can:
>
> (1) Trap this in the movqi expander, if you can fix up the general
> case without clobbering additional registers (unlikely).
> (2) Define a reload_outqi pattern to handle general m<-r moves.
> You then get a scratch register to play with. (This interface
> has changed (and improved) since I last used it.)
This option stands a reasonable chance of being the end result. It just adds
more hair than I'd like to. It is one more thing that could go wrong, and so
on.
> (3) Modify reload so that output memory operands are legitimised
> differently (only if you're brave).
> (4) Restrict QImode addresses to 'Q'.
>
> It looks downthread like you've already decided to do (4).
Only as a temporary measure.
> I just
> wasn't sure from the thread whether you realised that output reloads
> might be a specific problem.
I was not aware of this. It is only the second time I've seen postreload
complain about unsatisfied constraints. Thanks for pointing out this
problem.
--
Rask Ingemann Lambertsen
Re: [RFC] Optimization Diary
Tom Tromey wrote: "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: Devang> This version removes internal radar numbers and replaces s/ Devang> DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. * Why put the optimization diary into the object file? Why not just have -Wdiary and print it along with all the warnings? (I'm sure there's an answer to this, it would just be nice if it were in the document...) I'll use separate email to answer this because it needs some explanation and it may spawn its own little email thread. * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms of text highlighting. Why have a separate code here for "dead code" instead of just marking a text region and having a new _msg value meaning "dead code"? In the case of "dead code" we could use _msg. However, _cmd is available to trigger some actions in tools that use this information. If we let our imaginations run wild then for example, lead developer towards __restrict documentation (i.e. launch lang. standard doc in one window and open particular page). Usually tools directly communicate_msg in plain English without performing any action. * DW_AT_GNU_OD_category The last value is 0x 0016. That seems wrong, I think it should end in 0010. Yes. What are "action trails"? For example, Loop A is unrolled. It is not a parameter manipulation hint, it is not a limitation and it is not a hint to developers. It is just a report of what optimizer did. This is default category. Why is the action bit needed? The example in the text seems wrong, since there is an explicit _msg value for "function is inlined", and multiple values for why a function might not be inlined. It is used to provide distinctive feed back for action performed vs actions avoided. IDE may use different colors for actions performed vs actions avoided (blue vs salomn color :) How would the user find out what parameter is referred to by a parameter manipulation hint? I don't see where this is recorded. This should be encoded in msg text. It bit is used to distinguish build setting hint vs code change hint. Increase inline limit vs use __restrict. Parameter manipulation hints may be handled by build engineer in a big team, however you need code expert to justify use of __restrict. * DW_AT_GNU_OD_msg I presume that GCC will somehow maintain the canonical values here. It seems important that there be a central process for registering these so that weird divergences don't crop up over time. Also perhaps a "vendor extension" range should be specified? In any case, the mechanisms here ought to be documented. Yes. However, honestly, I do not know what is the best way to handle this. I am open for suggestion and I presume there is a established way to communicate such values, that are owned by GCC, to other tools. A nit: * The first example is oddly formatted. The blue region encompasses an entire comment, but the salmon (? nice color choice :) region stops before the '*/'. And... surely the diary won't be marking text regions corresponding to comments anyway? I feel like I'm probably misunderstanding the point of this highlighting. The second example is oddly formatted. Blue and salmon colored comments are generated by IDE based on diary entries. And IDE selected color based on action bit. - Devang
Re: [RFC] Optimization Diary
Tom Tromey wrote: * Why put the optimization diary into the object file? Why not just have -Wdiary and print it along with all the warnings? (I'm sure there's an answer to this, it would just be nice if it were in the document...) These are not warnings and they should not cause build failures when -Werror is used, hence warnings are not suitable medium to communicate this info. However, GCC provides hints along with warnings and errors. But they all reside in build log. While doing performance analysis, build log may not be available hence it is required to have it on disk somewhere. And text format is not suitable because of two reasons: 1) It is verbose. Try -opt_report in ICC. 2) This info is consumed by other tools (e.g. IDE, performance analyzer). It makes sense for a tool like Shark to use dwarf reader to get this info then parse raw text output. So, if 1) we need to keep this info on disk and available with final binary and 2) we use binary format to encode this info) then dwarf in object file is a natural selection. Command line developer can use extended dwarf reader to get the text messages. - Devang
Re: [RFC] Optimization Diary
> These are not warnings and they should not cause build failures > when -Werror is used, hence warnings are not suitable medium to > communicate this info. There is a third type of diagnostic in GCC which gets not much use at all. It is called note. It might be interesting to use that instead of saying there is no way to cause no build failures with warnings. Thanks, Andrew Pinski
Re: [RFC] Optimization Diary
Andrew Pinski wrote: These are not warnings and they should not cause build failures when -Werror is used, hence warnings are not suitable medium to communicate this info. There is a third type of diagnostic in GCC which gets not much use at all. It is called note. It might be interesting to use that instead of saying there is no way to cause no build failures with warnings. That's what I meant when I said "hints" ... "However, GCC provides (notes) along with warnings and errors. But they all reside in build log. While doing performance analysis, build log may not be available hence it is required to have it on disk somewhere. " - Devang
Re: [RFC] Optimization Diary
> > Andrew Pinski wrote: > >> These are not warnings and they should not cause build failures > >> when -Werror is used, hence warnings are not suitable medium to > >> communicate this info. > >> > > > > There is a third type of diagnostic in GCC which gets not much > > use at all. It is called note. It might be interesting to use that instead > > of saying there is no way to cause no build failures with warnings. > > > That's what I meant when I said "hints" ... > > "However, GCC provides (notes) along with warnings and errors. But they > all reside in build log. While doing performance analysis, build log > may not be available hence it is required to have it on disk somewhere. " If you are doing performance analysis the build log better be able to look at to make sure you are building with the correct options unless you trust the IDEs (which I and many other people don't). -- Pinski
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Tue, Jun 06, 2006 at 07:42:20AM +0200, Wolfgang Mües wrote: > Rask, > > On Monday 05 June 2006 16:16, Rask Ingemann Lambertsen wrote: > > I think the comment in arm.h is wrong. The manual seems to agree with > > the code. > > Just to make it easy for beginners... In mainline GCC, it is defined like this in arm/constraints.md: (define_memory_constraint "Q" "@internal In ARM state an address that is a single base register." (and (match_code "mem") (match_test "REG_P (XEXP (op, 0))"))) > Hmmm... I have searched 'Q' in the arm files. Not used in arm.md, only > for some variants of arm (cirrus). Maybe only implemented for them? > > I assume there is no way to tell the direction in > arm_legitimate_address_p() ? Hmmm. There isn't. arm_legitimate_address_p() just implements the macro GO_IF_LEGITIMATE_ADDRESS(MODE, X, LABEL). The only trick I know here is to use a different mode for special addresses. I'm writing an Intel 8086 backend which uses #define FUNCTION_MODE PQImode to let GO_IF_LEGITIMATE_ADDRESS handle function addresses specially. I just can't think of a way of using such a trick in this case. > > + swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0" > > You should get a price for cleverness here! Thanks! Indeed it looks good until you think of volatile variables. > > +; Avoid reading the stored value back if we have a spare register. > > +(define_peephole2 > > + [(match_scratch:QI 2 "r") [snip] > > As far as I can tell now, this works good. But I think there are many > cases in which the source operand is not needed after the store. Is > there a possibility to clobber the source operand and not using another > register? I don't know if (match_scratch ...) might reuse the source operand. It can be attempted more specifically with an additional peephole definition: (define_peephole2 [(set (match_operand:QI 0 "memory_operand" "") (match_operand:QI 1 "register_operand" ""))] "TARGET_ARM && TARGET_SWP_BYTE_WRITES && peep2_reg_dead_p (1, operands[1])" [(parallel [(set (match_dup 0) (match_dup 1)) (clobber (match_dup 1))] )] ) Yet another register which stands a good chance of being reusable is the register containing the address. This can be covered as well (assuming the match_scratch version doesn't do this): (define_peephole2 [(set (mem:QI (match_operand 0 "pmode_register_operand" "")) (match_operand:QI 1 "register_operand" ""))] "TARGET_ARM && TARGET_SWP_BYTE_WRITES && peep2_reg_dead_p (1, operands[0])" [(parallel [(set (mem:QI (match_dup 0)) (match_dup 1)) (clobber (match_dup 0))] )] ) I haven't tested these two peephole definitions. I can't think of any preferred order. It'll be your call, I guess. > > The register allocator chooses to use the lr register, in turn > > causing link register save alimination to fail, which doesn't help. > > I can't understand this without explanation... is it bad? GCC now needs more registers to hold addresses. The increased number of registers used disable som ARM specific optimizations of the function prologue and epilogue. This is bad, but only because the code becomes larger and slower. But I think that bytewritetest() suffers relatively much because it is a small function, using only a few registers to begin with. -- Rask Ingemann Lambertsen
Does Hegel Justify His Views?
I've studied a fair bit of analytic philosophy and feel that it is the rigorous arguments and detailed justification that separates worthwhile philosophy from mere speculation or faith based spiritual musings. Is there any reason for someone like me to take Hegel seriously? You've talked about the ideas he has but does he give us any good reason to believe they are true? Whenever I have tried to read Hegel I got the sense the arguments were incomplete and confused but I have to admit I haven't given him much of a chance. Does Hegel actually have good arguments for his views or is he just musing and throwing out ideas? If not why should we take him seriously? Peter (in Oakland)
Oops
Ignore that last email. It was sent to the wrong address. Peter Peter Gerdes -- [EMAIL PROTECTED] Find what I have to say interesting? Check out my blog or my analytic philosophy blog. On Jun 6, 2006, at 12:36 PM, Peter Michael Gerdes wrote: I've studied a fair bit of analytic philosophy and feel that it is the rigorous arguments and detailed justification that separates worthwhile philosophy from mere speculation or faith based spiritual musings. Is there any reason for someone like me to take Hegel seriously? You've talked about the ideas he has but does he give us any good reason to believe they are true? Whenever I have tried to read Hegel I got the sense the arguments were incomplete and confused but I have to admit I haven't given him much of a chance. Does Hegel actually have good arguments for his views or is he just musing and throwing out ideas? If not why should we take him seriously? Peter (in Oakland)
Re: Oops
On 6/6/06, Peter Michael Gerdes <[EMAIL PROTECTED]> wrote: Ignore that last email. It was sent to the wrong address. Thesis, antithesis, synthesis. -- David L Nicol "fans of liza minelli should always be disconnected immediately" -- Matthew Henry
Re: [RFC] Optimization Diary
Andrew Pinski wrote: Andrew Pinski wrote: These are not warnings and they should not cause build failures when -Werror is used, hence warnings are not suitable medium to communicate this info. There is a third type of diagnostic in GCC which gets not much use at all. It is called note. It might be interesting to use that instead of saying there is no way to cause no build failures with warnings. That's what I meant when I said "hints" ... "However, GCC provides (notes) along with warnings and errors. But they all reside in build log. While doing performance analysis, build log may not be available hence it is required to have it on disk somewhere. " If you are doing performance analysis the build log better be able to look at to make sure you are building with the correct options unless you trust the IDEs (which I and many other people don't). Two things. First this is not about IDE vs no IDE. Lets take one example. We, here at Apple, do not use IDE to build GCC. However we routinely install pre built compiler package on various machines and do compile time performance analysis using Shark. When Shark points me to a code hot spot, I want to know what optimizer was thinking about it. Second, optimization diary is not about what options are enabled and disabled. Compiler should not invoke any particular optimization pass just to add optimization diary entry. Its is a diary of optimization passes that are active. - Devang [ Interestingly, there is a long standing request, here at Apple, to list command line options in object file (even when optimization is not used). One of our intern tried to put them in STABS string. It may be a good idea to use DWARF in that case also. However it is orthogonal to optimization diary. It is a good small project, if someone is interested. ]
Re: Does Hegel Justify His Views?
On Tue, Jun 06, 2006 at 12:36:42PM -0700, Peter Michael Gerdes wrote: > > Does Hegel actually have good arguments for his views or is he just > musing and throwing out ideas? If not why should we take him seriously? I don't think any of his patches have been accepted by GCC, so I'd say his arguments must not be very good. It's easy to see why: I downloaded _Pha:nomenologie des Geistes_ from Project Gutenberg and it won't even compile. There are in fact an astonishing number of the most basic syntax errors; it reads like something written by someone who didn't know C at all. Really atrocious coding, plus the comments are in German. Besides, we already have a Hegelian dialectic in GCC (C: thesis, C++: antithesis, Java: synthesis), so what do we need him for? Dustin pgpcNULfgid0J.pgp Description: PGP signature
Re: [RFC] Optimization Diary
Devang Patel <[EMAIL PROTECTED]> writes: | Tom Tromey wrote: | > * Why put the optimization diary into the object file? | > Why not just have -Wdiary and print it along with all the warnings? | > (I'm sure there's an answer to this, it would just be nice if it | > were in the document...) | > | These are not warnings and they should not cause build failures | when -Werror is used, hence warnings are not suitable medium to | communicate this info. The diagnostic machinery has the "note" diagnostic kind; and the diagnostic can have customized prefixes, e.g. "note: ". -- Gaby
Re: [RFC] Optimization Diary
Devang Patel <[EMAIL PROTECTED]> writes: | [ Interestingly, there is a long standing request, here at Apple, to list | command line options in object file (even when optimization is not used). | One of our intern tried to put them in STABS string. It may be a good | idea to use DWARF in that case also. However it is orthogonal to | optimization diary. It is a good small project, if someone is | interested. ] I was under the impression that it was sort tkane care of by some patches from CodeSourcery. Though, it is possible I may have dreamted. -- Gaby
Re: [RFC] Optimization Diary
Hi Devang, > - > Devang > > [ Interestingly, there is a long standing request, here at Apple, to list > command line options in object file (even when optimization is not used). > One of our intern tried to put them in STABS string. It may be a good > idea to use DWARF in that case also. However it is orthogonal to > optimization diary. It is a good small project, if someone is > interested. ] > Is this what you want ? This doesn't use DWARF but just has a separate section options section which contains all the options passed. http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01119.html It seems to be awaiting review. cheers Ramana
Re: [RFC] Optimization Diary
On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote: > Devang Patel <[EMAIL PROTECTED]> writes: > > | [ Interestingly, there is a long standing request, here at Apple, to list > | command line options in object file (even when optimization is not used). > | One of our intern tried to put them in STABS string. It may be a good > | idea to use DWARF in that case also. However it is orthogonal to > | optimization diary. It is a good small project, if someone is > | interested. ] > > I was under the impression that it was sort tkane care of by some > patches from CodeSourcery. Though, it is possible I may have dreamted. Nope, it was Nick. -- Daniel Jacobowitz CodeSourcery
Re: [RFC] Optimization Diary
Is this what you want ? yes :) Thanks, - Devang
Re: [wwwdocs] Complete revamp of our web site
On Mon, Jun 05, 2006 at 09:53:00PM -0700, Andrew Pinski wrote: > Also what about moving the News up to a noticeable spot since right now > it is down in a corner so it looks out of place. In fact on my screen > which is set to 1024x768, I have to scroll to get to the news. Yes, the top news needs to be on the front page, anything you have to scroll down for effectively isn't on the front page.
Re: [RFC] Optimization Diary
Tom Tromey wrote: >> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: > > Devang> This version removes internal radar numbers and replaces s/ > Devang> DW_AT_APPLE.../DW_AT_GNU... > > I read this. I'm not anywhere near an expert in dwarf or anything > related to this proposal, so please bear with me if I say something > dumb :-). > > I do have a few questions and concerns. > > In addition to Tom's concerns, it seems to me to be a *really bad idea* to try to come up with integer values for every single message, instead of just placing a string there. If you are worried about space usage, you needn't be. Any sane compiler will place the strings in the .debug_str section, and they will only appear once (ld even does cross-object-file string section merging here). If you are worried about the strings not being canonical from version to version, then just enforce them being canonical at the compiler level. The easiest way there is to just put a comment before the function or whatever that generates the string saying it shouldn't be changed between versions.
Re: [RFC] Optimization Diary
On Tue, 6 Jun 2006, Daniel Jacobowitz wrote: | On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote: | > Devang Patel <[EMAIL PROTECTED]> writes: | > | > | [ Interestingly, there is a long standing request, here at Apple, to list | > | command line options in object file (even when optimization is not used). | > | One of our intern tried to put them in STABS string. It may be a good | > | idea to use DWARF in that case also. However it is orthogonal to | > | optimization diary. It is a good small project, if someone is | > | interested. ] | > | > I was under the impression that it was sort tkane care of by some | > patches from CodeSourcery. Though, it is possible I may have dreamted. | | Nope, it was Nick. Thanks for the correction. My apologies to Nick. -- Gaby
Re: [RFC] Optimization Diary
> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: Tom> * Why put the optimization diary into the object file? [...] Devang> 2) This info is consumed by other tools (e.g. IDE, performance Devang> analyzer). It makes sense for a tool like Shark to use dwarf Devang> reader to get this info then parse raw text output. Thanks, this makes sense to me. I suggest adding this to your document as rationale. Tom
Re: [RFC] Optimization Diary
> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: >> * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms >> of text highlighting. Why have a separate code here for "dead >> code" instead of just marking a text region and having a new _msg >> value meaning "dead code"? Devang> In the case of "dead code" we could use _msg. However, _cmd is Devang> available to trigger some actions in tools that use this Devang> information. If we let our imaginations run wild then for Devang> example, lead developer towards __restrict documentation Devang> (i.e. launch lang. standard doc in one window and open Devang> particular page). I agree, interconnections like the above are cool and useful. But this approach seems weird, because it is asking compiler maintainers to decide whether a given result is a message or an action. I think it would be more natural for the compiler to say what did or did not happen, and then to have the IDE, or whatever, apply interpretation to the record of the facts. I.e., no message/action distinction. >> What are "action trails"? Devang> For example, Loop A is unrolled. It is not a parameter Devang> manipulation hint, it is not a limitation and it is not a hint Devang> to developers. It is just a report of what optimizer did. This Devang> is default category. Ok. Why are these things stored in bits and not as a enumeration of possible values? Usually the use of bits implies that combinations of them are valid, but here it sounds as though the values are actually independent. >> How would the user find out what parameter is referred to by a >> parameter manipulation hint? I don't see where this is recorded. Devang> This should be encoded in msg text. You mean it is implicit in the _msg value? If so, then the linkage between a given _msg value and a particular option ought to be documented. I realize this can't be done in a DWARF spec, but it at least needs to be done in GCC somewhere... it would be helpful to have this spelled out. Tom
Re: [RFC] Optimization Diary
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes: Dan> In addition to Tom's concerns, it seems to me to be a *really bad idea* Dan> to try to come up with integer values for every single message, instead Dan> of just placing a string there. One reason to prefer the numerical approach is that it makes localization of the user interface simpler. Dan> The easiest way there is to just put a comment before the function or Dan> whatever that generates the string saying it shouldn't be changed Dan> between versions. We would also have to constrain the messages not to have any printf-style substitutions, since that would be an i18n disaster. Otherwise, yeah, I was wondering about this myself. Tom
Re: [RFC] Optimization Diary
Daniel Berlin <[EMAIL PROTECTED]> writes: > Tom Tromey wrote: > >> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: > > > > Devang> This version removes internal radar numbers and replaces s/ > > Devang> DW_AT_APPLE.../DW_AT_GNU... > > > > I read this. I'm not anywhere near an expert in dwarf or anything > > related to this proposal, so please bear with me if I say something > > dumb :-). > > > > I do have a few questions and concerns. > > > > > In addition to Tom's concerns, it seems to me to be a *really bad idea* > to try to come up with integer values for every single message, instead > of just placing a string there. One issue here is that this interacts poorly with internationalization. No matter what you do, you'll need to have a table of possible strings somewhere, so you might as well save space by not putting it in every object file.
Re: [RFC] Optimization Diary
Geoffrey Keating wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > >> Tom Tromey wrote: "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: >>> Devang> This version removes internal radar numbers and replaces s/ >>> Devang> DW_AT_APPLE.../DW_AT_GNU... >>> >>> I read this. I'm not anywhere near an expert in dwarf or anything >>> related to this proposal, so please bear with me if I say something >>> dumb :-). >>> >>> I do have a few questions and concerns. >>> >>> >> In addition to Tom's concerns, it seems to me to be a *really bad idea* >> to try to come up with integer values for every single message, instead >> of just placing a string there. > > One issue here is that this interacts poorly with > internationalization. > No matter what you do, you'll need to have a > table of possible strings somewhere, so you might as well save space > by not putting it in every object file. I believe this is a red herring. We control the debug output machinery generating this, and can simply tell it to only deal in one language. Trying to catalogue and assign a permanent place and number to every single optimization message a compiler can generate is a much much much worse idea, IMHO.
Re: [RFC] Optimization Diary
> > Trying to catalogue and assign a permanent place and number to every > single optimization message a compiler can generate is a much much much > worse idea, IMHO. In the same way numbering warning messages is a bad idea (yes ICC and a couple other compilers do but we should not). -- Pinski
Re: [RFC] Optimization Diary
On 06/06/2006, at 4:58 PM, Daniel Berlin wrote: Geoffrey Keating wrote: Daniel Berlin <[EMAIL PROTECTED]> writes: Tom Tromey wrote: "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: Devang> This version removes internal radar numbers and replaces s/ Devang> DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. In addition to Tom's concerns, it seems to me to be a *really bad idea* to try to come up with integer values for every single message, instead of just placing a string there. One issue here is that this interacts poorly with internationalization. No matter what you do, you'll need to have a table of possible strings somewhere, so you might as well save space by not putting it in every object file. I believe this is a red herring. We control the debug output machinery generating this, and can simply tell it to only deal in one language. I'm not concerned about what goes into the .o file, but what gets displayed on the screen. We cannot tell users to "deal in one language". Trying to catalogue and assign a permanent place and number to every single optimization message a compiler can generate is a much much much worse idea, IMHO. Alternatively, we could put *every* supported language into the .o file. But that bloats object files even more... smime.p7s Description: S/MIME cryptographic signature
Re: [RFC] Optimization Diary
Geoffrey Keating wrote: > On 06/06/2006, at 4:58 PM, Daniel Berlin wrote: > >> Geoffrey Keating wrote: >>> Daniel Berlin <[EMAIL PROTECTED]> writes: >>> Tom Tromey wrote: >> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: > Devang> This version removes internal radar numbers and replaces s/ > Devang> DW_AT_APPLE.../DW_AT_GNU... > > I read this. I'm not anywhere near an expert in dwarf or anything > related to this proposal, so please bear with me if I say something > dumb :-). > > I do have a few questions and concerns. > > In addition to Tom's concerns, it seems to me to be a *really bad idea* to try to come up with integer values for every single message, instead of just placing a string there. >>> One issue here is that this interacts poorly with >>> internationalization. >>> No matter what you do, you'll need to have a >>> table of possible strings somewhere, so you might as well save space >>> by not putting it in every object file. >> I believe this is a red herring. >> We control the debug output machinery generating this, and can simply >> tell it to only deal in one language. > > I'm not concerned about what goes into the .o file, but what gets > displayed on the screen. We cannot tell users to "deal in one > language". > You still need to be able to display the message for each number in all the languages you want, so it's going to be stored somewhere, you haven't solved the problem, just moved it completely to the consumer. >> Trying to catalogue and assign a permanent place and number to every >> single optimization message a compiler can generate is a much much >> much >> worse idea, IMHO. > > Alternatively, we could put *every* supported language into the .o > file. But that bloats object files even more... I have a very hard time believing that compiling and outputting messages in one language, and having someone who can't read those messages optimize and profile your application in another language, is a significant enough use case to be worried about. You can disagree. I'm just trying to tell you this has almost zero hope of ever being standardized if you keep it as a bunch of numbers. It also has almost zero hope of working over multiple compiler versions, being future proof in general, and not having other compiler vendors fight over message number namespace. --Dan
Re: [RFC] Optimization Diary
On 06/06/2006, at 5:11 PM, Daniel Berlin wrote: Geoffrey Keating wrote: On 06/06/2006, at 4:58 PM, Daniel Berlin wrote: Geoffrey Keating wrote: Daniel Berlin <[EMAIL PROTECTED]> writes: Tom Tromey wrote: "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: Devang> This version removes internal radar numbers and replaces s/ Devang> DW_AT_APPLE.../DW_AT_GNU... I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something dumb :-). I do have a few questions and concerns. In addition to Tom's concerns, it seems to me to be a *really bad idea* to try to come up with integer values for every single message, instead of just placing a string there. One issue here is that this interacts poorly with internationalization. No matter what you do, you'll need to have a table of possible strings somewhere, so you might as well save space by not putting it in every object file. I believe this is a red herring. We control the debug output machinery generating this, and can simply tell it to only deal in one language. I'm not concerned about what goes into the .o file, but what gets displayed on the screen. We cannot tell users to "deal in one language". You still need to be able to display the message for each number in all the languages you want, so it's going to be stored somewhere, you haven't solved the problem, just moved it completely to the consumer. Yes. However, you also get smaller .o files. Trying to catalogue and assign a permanent place and number to every single optimization message a compiler can generate is a much much much worse idea, IMHO. Alternatively, we could put *every* supported language into the .o file. But that bloats object files even more... I have a very hard time believing that compiling and outputting messages in one language, and having someone who can't read those messages optimize and profile your application in another language, is a significant enough use case to be worried about. Right above, you said "We control the debug output machinery generating this, and can simply tell it to only deal in one language." Here, you seem to be implying that the messages should be localised in the language the compiler is going to output messages in. I suppose you could output both, but that still bloats object files more than just using numbers. smime.p7s Description: S/MIME cryptographic signature
Re: [RFC] Optimization Diary
> Right above, you said "We control the debug output machinery > generating this, and can simply tell it to only deal in one > language." Here, you seem to be implying that the messages should be > localised in the language the compiler is going to output messages > in. I suppose you could output both, but that still bloats object > files more than just using numbers. Just output in English and let the IDE or the other tools translate it. -- Pinski
Re: [RFC] Optimization Diary
On 06/06/2006, at 5:20 PM, Andrew Pinski wrote: Right above, you said "We control the debug output machinery generating this, and can simply tell it to only deal in one language." Here, you seem to be implying that the messages should be localised in the language the compiler is going to output messages in. I suppose you could output both, but that still bloats object files more than just using numbers. Just output in English and let the IDE or the other tools translate it. What's the difference between that and just outputting a number and letting the IDE or other tool translate it? Either way, you're going to need a fixed set of strings or numbers to translate. smime.p7s Description: S/MIME cryptographic signature
Re: [RFC] Optimization Diary
> > > --Apple-Mail-9--465959030 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > delsp=yes; > format=flowed > > > On 06/06/2006, at 5:20 PM, Andrew Pinski wrote: > > >> Right above, you said "We control the debug output machinery > >> generating this, and can simply tell it to only deal in one > >> language." Here, you seem to be implying that the messages should be > >> localised in the language the compiler is going to output messages > >> in. I suppose you could output both, but that still bloats object > >> files more than just using numbers. > > > > Just output in English and let the IDE or the other tools translate > > it. > > What's the difference between that and just outputting a number and > letting the IDE or other tool translate it? Either way, you're going > to need a fixed set of strings or numbers to translate. Say I want to add a new one, I have to go through a committee with the number system while with a string I don't. -- Pinski
Re: [RFC] Optimization Diary
On 06/06/2006, at 5:25 PM, Andrew Pinski wrote: On 06/06/2006, at 5:20 PM, Andrew Pinski wrote: Right above, you said "We control the debug output machinery generating this, and can simply tell it to only deal in one language." Here, you seem to be implying that the messages should be localised in the language the compiler is going to output messages in. I suppose you could output both, but that still bloats object files more than just using numbers. Just output in English and let the IDE or the other tools translate it. What's the difference between that and just outputting a number and letting the IDE or other tool translate it? Either way, you're going to need a fixed set of strings or numbers to translate. Say I want to add a new one, I have to go through a committee with the number system while with a string I don't. I don't see how making it a string makes this different. Either your new string will be a standard string or it won't. Either your new number will be a standard number or it won't. If you want it to be standard, you have to go through the committee. smime.p7s Description: S/MIME cryptographic signature
Re: [RFC] Optimization Diary
> I don't see how making it a string makes this different. Either your > new string will be a standard string or it won't. Either your new > number will be a standard number or it won't. If you want it to be > standard, you have to go through the committee. I don't understand why it has to be a "standard" string/message. Yes there could be some base set of messages. Also with the number system, you have to update the IDE when news ones get added while with the message way you don't unless you want to translate it to another language. -- Pinski
Re: which cctool on Darwin?
I believe I may have discovered the component that was causing the c++ regressions I was seeing on Darwin when fink was sourced. I have found that after I deinstalled bison v2.1 installed by fink, I was able to build gcc trunk on MacOS X 10.4 with fink sourced and still pass the c++ testsuite properly. I have built bison v2.3 and will see if that shows the same behavior as v2.1. Have there been any reports of problems with bison v2.1 and gcc trunk? Jack
Re: [RFC] Optimization Diary
On Tue, Jun 06, 2006 at 05:36:33PM -0700, Geoffrey Keating wrote: > I don't see how making it a string makes this different. Either your > new string will be a standard string or it won't. Either your new > number will be a standard number or it won't. If you want it to be > standard, you have to go through the committee. In practice, using string identifiers does make conflicts less likely. It's also easier for a vendor to pick a unique prefix and be confident that Apple isn't going to assign some other meaning to "csl-inline-bart". -- Daniel Jacobowitz CodeSourcery
Re: TLS on windows (was: Re: Gfortran on Windows (mingw32) with OpenMP)
Hi, all, After I refer to the Intel paper titled "Threading Methodology : Principles and Practices" versin 2.0 published in 2003, I note the following message in the article mentioning:(from page 22, web site : http://cache-www.intel.com/cd/00/00/21/93/219349_threadingmethodology.pdf) _ OpenMP and thread libraries have mechanisms to create thread-local storage. Threads can safely access this storage without synchronization. Use the following declarations to create thread-local storage in different threading models: In OpenMP use threadprivate In Win32, use the TlsAlloc() function In Pthreads, use the pthread_key_create function __ >From the above description, I think that "gfortran with OpenMP" compiler can also implemented the TLS using Win32 threads or Pthreads. Please comment on the above implementation methods. Thanks. Best regards, Henry Kar Ming Chan --- FX Coudert <[EMAIL PROTECTED]> wrote: > [First, a warning: I'm neither an expert in TLS, nor > in Windows nor > in GCC guts > > > can we have chance to solve the > > problem of threadprivate by adding the TLS support > to > > mingw32? > > The support for TLS (Thread Local Storage) would > probably come from > the compiler itself. Windows has TLS (see for > example http:// > dotnet.di.unipi.it/Content/sscli/docs/doxygen/pal/localstorage_8c- > > source.html and > http://www.ddj.com/dept/cpp/184403874, or the MSDN > documentation at > http://msdn.microsoft.com/library/default.asp?url=/ > library/en-us/dllproc/base/tlsalloc.asp), so you'd > "only" need to > teach GCC how to call that. > > Now, I don't have competence, time and motivation to > do that. So, if > my analysis above is correct, there are three things > you can do: ask > around here if someone is interested in this and is > planning to do > it; do it yourself, if you have the competence; find > someone you > know, that you have leverage on, to do it :) > > Now, for an idea of how much work it represents... > perhaps someone > here can tell us? > > FX > Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [RFC] Optimization Diary
Daniel Jacobowitz wrote: On Tue, Jun 06, 2006 at 05:36:33PM -0700, Geoffrey Keating wrote: I don't see how making it a string makes this different. Either your new string will be a standard string or it won't. Either your new number will be a standard number or it won't. If you want it to be standard, you have to go through the committee. In practice, using string identifiers does make conflicts less likely. It's also easier for a vendor to pick a unique prefix and be confident that Apple isn't going to assign some other meaning to "csl-inline-bart". We can allocate space in numbering for vendor extensions. - Devang
Re: [RFC] Optimization Diary
Tom Tromey wrote: "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: Tom> * Why put the optimization diary into the object file? [...] Devang> 2) This info is consumed by other tools (e.g. IDE, performance Devang> analyzer). It makes sense for a tool like Shark to use dwarf Devang> reader to get this info then parse raw text output. Thanks, this makes sense to me. I suggest adding this to your document as rationale. OK. - Devang
Re: [RFC] Optimization Diary
On Jun 6, 2006, at 9:49 PM, Devang Patel wrote: We can allocate space in numbering for vendor extensions. What happens when you compile two sources with two different compilers and they use the same number for vendor extension? You just end up with weird results in the IDE or performance analysis program. Also what happens after you fill up the vendor extension range? Also what happens when you change your compiler but not IDE, but you don't want to update the IDE? Like for an example I compile myself GCC 5.0.0 which adds LTO and you get more data (that was not implemented in 4.2.0). I personally don't have access to Xcode sources to get an updated version or Shark code (unless you are going to release them into open source which I doubt Apple wants that). I want all the new features of GCC 5.0.0 and the new optimization diary support and there is no way to get that support with numbers. With messages I get all this support for free and you don't need a mapping in the IDE at all (unless you want translation). Oh, by the way does Xcode provide a way to change the language which the error messages are outputted because I cannot find one? -- Pinski
Re: [RFC] Optimization Diary
Tom Tromey wrote: "Devang" == Devang Patel <[EMAIL PROTECTED]> writes: * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms of text highlighting. Why have a separate code here for "dead code" instead of just marking a text region and having a new _msg value meaning "dead code"? Devang> In the case of "dead code" we could use _msg. However, _cmd is Devang> available to trigger some actions in tools that use this Devang> information. If we let our imaginations run wild then for Devang> example, lead developer towards __restrict documentation Devang> (i.e. launch lang. standard doc in one window and open Devang> particular page). I agree, interconnections like the above are cool and useful. But this approach seems weird, because it is asking compiler maintainers to decide whether a given result is a message or an action. I think it would be more natural for the compiler to say what did or did not happen, and then to have the IDE, or whatever, apply interpretation to the record of the facts. I.e., no message/action distinction. I understand what you are saying. I will give this more thought and get back to you. What are "action trails"? Devang> For example, Loop A is unrolled. It is not a parameter Devang> manipulation hint, it is not a limitation and it is not a hint Devang> to developers. It is just a report of what optimizer did. This Devang> is default category. Ok. Why are these things stored in bits and not as a enumeration of possible values? Usually the use of bits implies that combinations of them are valid, but here it sounds as though the values are actually independent. Exactly, combinations are valid. For example, - when loop is vectorized using peeling to handle unknown alignment then it is - action performed plus hint (possible use of explicit alignment attributes) - When loop is vectorized using peeling to handle known misalignment then it is only action performed. - When loop is not vectorized because of alignment issues then it is a hint as well as lack of action - When loop is not vectorized because multiple misalignments then it is a lack of action plus limitation plus hint It is possible that this is too much info and in general it may not be applicable to other optimizations, but this is starting point for my thought process. How would the user find out what parameter is referred to by a parameter manipulation hint? I don't see where this is recorded. Devang> This should be encoded in msg text. You mean it is implicit in the _msg value? If so, then the linkage between a given _msg value and a particular option ought to be documented. I realize this can't be done in a DWARF spec, but it at least needs to be done in GCC somewhere... it would be helpful to have this spelled out. Yes. I have not spent time to catalog all interesting messages (and I'll need help here). I admit, I have concentrated mostly from vectorizer point of view. - Devang
Re: Modifying ARM code generator for elimination of 8bit writes - need help
Rask, On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote: > > > + swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0" > > > > You should get a price for cleverness here! > > Thanks! Indeed it looks good until you think of volatile variables. Because volatile variables can change their values from another thread, and the readback will be false. Oh. gcc knows the volatile attribute here, I assume? > > As far as I can tell now, this works good. But I think there are > > many cases in which the source operand is not needed after the > > store. Is there a possibility to clobber the source operand and not > > using another register? > > I don't know if (match_scratch ...) might reuse the source operand. > It can be attempted more specifically with an additional peephole > definition: > > (define_peephole2 > [(set (match_operand:QI 0 "memory_operand" "") > (match_operand:QI 1 "register_operand" ""))] > "TARGET_ARM && TARGET_SWP_BYTE_WRITES && peep2_reg_dead_p (1, > operands[1])" [(parallel > [(set (match_dup 0) (match_dup 1)) > (clobber (match_dup 1))] > )] > ) I will try this. > Yet another register which stands a good chance of being reusable is > the register containing the address. Yes, but that is not allowed according to the specification of the swp instruction. The address register must be different from the other 2 registers. Is there any chance of gcc violating this constraint? regards Wolfgang -- We're back to the times when men were men and wrote their own device drivers. (Linus Torvalds)
Re: [RFC] Optimization Diary
Andrew Pinski wrote: On Jun 6, 2006, at 9:49 PM, Devang Patel wrote: We can allocate space in numbering for vendor extensions. What happens when you compile two sources with two different compilers and they use the same number for vendor extension? What happens when another compiler uses 0x4104 TAG value for something else and GCC uses it for DW_TAG_GNU_BINCL ? You just end up with weird results in the IDE or performance analysis program. Also what happens after you fill up the vendor extension range? What happens when vendor extension range for TAGs and Attributes are full ? Also what happens when you change your compiler but not IDE, but you don't want to update the IDE? What happens when GCC adds new DWARF extension but you do not want to update GDB ? - Devang
Re: [RFC] Optimization Diary
On Jun 6, 2006, at 10:34 PM, Devang Patel wrote: Andrew Pinski wrote: On Jun 6, 2006, at 9:49 PM, Devang Patel wrote: We can allocate space in numbering for vendor extensions. What happens when you compile two sources with two different compilers and they use the same number for vendor extension? What happens when another compiler uses 0x4104 TAG value for something else and GCC uses it for DW_TAG_GNU_BINCL ? Not my fault and not really related because we are creating a new standard and don't want to repeat this mistake, messages don't have this issue. You just end up with weird results in the IDE or performance analysis program. Also what happens after you fill up the vendor extension range? What happens when vendor extension range for TAGs and Attributes are full ? Who cares, we are trying making something which is useful and not making something which is going to be limited. Also what happens when you change your compiler but not IDE, but you don't want to update the IDE? What happens when GCC adds new DWARF extension but you do not want to update GDB ? Again, we are trying to make something useful and extendable. If you don't care about usefulness and extendibility then go ahead and use numbers. Having the message gets rid of having duplicated code in each program that processes the numbers, you have the message right away without doing extra work. You really should listen to Daniel Berlin if you ever want this to be officially part of the dwarf2 standard. Remember he is part of the committee there. You get extendibility for free and no need to change the IDE every thing you want to add a new diary entry. What more do you want something for free or something which limits the use? If you want something which is limited you may as well then just not use dwarf2 and instead write out a text file. -- Pinski
Re: which cctool on Darwin?
I have finished a build of gcc trunk on Darwin with a fink package of bison 2.3 installed and can confirm that the c++ regressions I saw with bison 2.1 installed have disappeared. So there must be some problem with bison 2.1 and gcc trunk (at least on Darwin). Jack
